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Preface 
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puters.  1  sincerely  hope  that  users  will  find  the  program 
helpful.  Any  user  who  would  like  to  obtain  a  copy  of  the 
software  or  who  would  like  to  submit  recommendat i ons  or 
suggestions  for  program  modification  should  contact  me  at: 
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Abstract 


The  increasing  complexity  o-f  today’s  business  and 
military  decisions  demand  in-formed  decision  making  at  all 
levels  o-f  management.  Such  decision  making  must  be  fully 
supported  by  timely  and  accurate  analysis.  Computers  are 
well-suited  for  such  analysis.  Unfortunately,  the  large 
mainframe  computers  are  not  flexible  or  responsive  enough 
for  use  by  most  managers  in  a  timely  manner. 

The  growing  popularity,  presence,  and  capability  of 
microcomputers  represents  a  new  opportunity  for  operations 
research.  These  small,  low-cost  machines  can  provide  much 
of  the  computer  support  needed  for  decision  making  by  man¬ 
agers  and  analysts  provided  that  the  necessary  software 
tools  are  developed. 

This  -study^was  undertaken  to  provide  a  user — oriented 
decision  analysis  tool  which  exploits  the  advantages  of  per¬ 
sonal  computers.  Of  the  many  useful  quantitative  techniques 
available,  the  weighting  and  constraint  techniques  of  multi¬ 
objective  decision  analysis  were  selected  and  implemented. 


PERSONAL  COMPUTER  AIDED 


DECISION  ANALYSIS 

I  Introducti on 

The  impact  of  microcomputers  on  management  decision 
making  has  been  and  will  continue  to  be  complex  and  -far 
reaching  (30:921).  As  the  cost  o-f  hardware  declines,  and 
the  variety  o-f  available  software  increases,  more  and  more 
managers  use  and  rely  on  microcomputers  on  a  daily  basis. 
Unf ortunatel y ,  the  use  o-f  the  microcomputer  as  a  management 
tool  has,  to  date,  been  limited  mainly  to  -financial  manage¬ 
ment  and  to  the  bookkeeping  needs  o-f  smaller  -firms  (20:297). 
The  more  complex  operations  research  techniques  have,  -for 
the  most  part,  remained  inaccessible  to  the  line  manager. 
They  exist  as  parts  o-f  complicated  software  packages  on 
large-scale  computers  that  usually  require  both  operations 
research  department  and  data  processing  department  assist¬ 
ance  to  access.  This  inaccessibility  has  tended  to  frus¬ 
trate  managers  and  has  generally  inhibited  the  application 
of  operations  research  techniques  to  real  world  problems 
(16:16).  As  a  result,  many  feel  that  operations  research 
has  failed  to  reach  it’s  potential,  beyond  an  academic 
environment  (1:93). 

The  first  microcomputers  were  not  much  help  since  they 


did  not  possess  the  computing  power  necessary  -for  complex 
operations  research  techniques.  However,  over  the  past 
thirteen  years,  since  the  first  mi croprocessor  was  intro¬ 
duced  (5:198),  technology  has  improved  microcomputer  capa¬ 
bilities  such  that  most  operations  research  techniques  can 
readily  be  handled  by  a  majority  of  today's  most  commonly 
available  personal  computers. 

These  two  developments,  the  widespread  acceptance  of 
microcomputers  and  the  rapid  increase  in  microcomputer 
capabi 1 i t i es,  represent  a  new  opportunity  for  operations 
research  to  fulfill  it’s  potential  in  a  non— academic  envi¬ 
ronment  (11:251).  However,  for  this  to  occur,  software 
tools  must  be  developed  that  provide  business  and  military 
leaders  the  means  to  use  their  microcomputers  to  apply 
operations  research  techniques  to  real  world  problems. 
Already,  software  vendors,  in  an  attempt  to  meet  expanding 
needs,  are  beginning  to  incorporate  some  operations  research 
technology  in  their  new  offerings.  For  example,  project 
management  and  inventory  control  are  already  commercially 
available  (16:17).  To  a  degree,  this  commercial  software 
development  is  healthy,  however,  the  introduction  of  these 
tools  as  software  innovations  rather  than  MS/OR  innovations 
leads  to  the  risks  usually  associated  with  loss  of  quality 
control.  Poorly  designed  tools  will  be  resisted  by  manage¬ 
ment  and  will  do  little  to  improve  the  already  weak 
academi c/management  relationship  (16:17). 


Magnifying  the  importance  o-f  applying  operations 
research  techniques  to  microcomputers  is  the  increasing 
complexity  of  today's  business  and  military  decisions.  In 
addition,  the  consequences  of  making  incorrect  decisions  are 
frequently  so  severe  that  better  decision  making  capabili¬ 
ties  are  becoming  increasingly  essential.  Operations  re¬ 
search  techniques  and  today’s  personal  computers  provide  one 
means  of  improving  management’s  decision  making  ability. 
The  limited  inventory  of  effective,  manager  oriented  soft¬ 
ware  tools  is  the  major  obstacle  which  prevents  realization 
of  this  goal.  An  analysis  of  the  decision  making  process 
helps  to  reveal  the  next  logical  place  where  microcomputer 
implementation  efforts  should  be  directed. 

Decision  making  is  an  essential  aspect  of  all  of  our 
daily  lives  (6:4).  Even  the  simplest  situations  involve  the 
decision  making  process.  What  clothes  to  wear;  What  food 
to  eat;  or  what  activities  to  undertake,  are  but  a  small 
sample  of  the  thousands  of  decisions  we  all  make  each  day. 
But  how  do  we  make  these  decisions?  In  general ,  our 
decisions  are  made  to  optimize  some  condition  based  on  an 
analysis  of  the  situation  (31:14). 

For  example,  in  deciding  what  clothes  to  wear,  we  may 
base  our  decision  on:  what  is  clean,  what  the  weather  is 
like,  and/or  what  type  of  activities  we  plan  to  undertake. 
In  general,  some  subset  of  our  wardrobe  will  be  appropriate 


for  the  situation  while  the  rest  will  not 


That  is,  some  of 


our  clothes  will  be  dirty,  or  not  warm  enough,  or  not 
"•fancy"  enough,  etc.  Once  this  acceptable  subset  of  our 
wardrobe  has  been  established,  we  then  select  that  outfit 
which  optimises  some  situation  (or  set  of  conditions). 
Examples  of  the  conditions  we  may  wish  to  optimize  in  this 
case,  would  be: 

"to  look  the  best",  or 

"to  be  the  most  comfortable". 

The  situation  character! sties  that  establish  "what  is 
appropr i ate"  are  usually  referred  to  as  the  constraints 
(31:570).  The  condition  we  are  attempting  to  optimize  is 
usually  referred  to  as  an  objective  (31:572).  Thus  the 
decision  process  involves  optimizing  some  objective  subject 
to  one  or  more  constraints  (31:43). 

Of  course,  for  most  of  our  everyday  decisions  we  do  not 
consciously  enumerate  constraints  and  objectives.  For  most 
of  these  decisions,  we  rely  on  our  instincts  or  intuition. 
However,  as  the  problem  grows  in  importance,  complexity  or 
size  we  can  no  longer  rely  on  our  intuition.  For  these 
decisions,  operations  research  decision  making  aids  such  as 
linear  programming  can  help  us  make  the  best  decisions. 
Several  successful  microcomputer  applications  of  linear 
programming  have  previously  been  demonstrated  (10,  12). 

The  decision  making  task  is  further  complicated  when  we 
wish  to  optimize  two  or  more  objectives  simultaneously. 


Usually,  with  these  multi  objective  problems  improving  one 
objective  results  in  hurting  at  least  one  of  the  other 
objectives  (6:16).  The  objectives  usually  compete  for  the 
same  scarce  resources. 

These  types  of  mul t i ob j ect i ve  problems  are  common  in 
today’s  fast-paced  and  complex  society.  Both  business  and 
military  leaders  are  faced  with  these  types  of  problems 
daily.  The  consequences  of  suboptimal  decisions  for  these 
problems  can  be  far — reaching  and  in  some  cases  catastrophic 
(31:4).  A  microcomputer  aid  for  dealing  with  multiobjective 
decision  problems  would  be  a  useful  decision  making  tool.  A 
literature  survey  has  revealed  no  such  application-  to  date. 

Microcomputer  implementation  of  a  mul ti object i ve  deci¬ 
sion  tool  is  a  problem  with  two  dimensions.  It  is  indeed  a 
software  problem  in  that  the  complexity  of  the  techniques  to 
be  programmed  will  require  taking  full  advantage  of  the  com¬ 
puter’s  capabilities  in  order  to  run  at  all  (27:294).  But 
more  importantly,  the  problem  has  an  operations  research 
orientation.  That  is,  the  key  to  success  of  the  program  is 
the  creation  of  a  problem  solving  environment  that  can  be 
used  directly  by  the  manager  in  addition  to  the  operations 
research  staff  (16:18).  Thus,  rather  than  simply  an  issue 
of  correctly  programming  a  technique,  the  problem  involves 
technique  selection  and  design,  user  interface,  and  user 
friendliness.  All  of  these  latter  issues  can  best  be  re¬ 
solved  by  the  operations  research  specialist  (18:275). 


•  y.  \  V  - 


Problem  Statement  and  Scope 

The  increasing  costs  o-f  incorrect  decisions  have  im¬ 
plied  a  need  to  improve  the  decision  making  aids  available 
to  industrial  and  military  leaders.  Operations  research  and 
the  availability  o-f  microcomputers  have  provided  the  means 
to  do  so.  Successful  implementation  of  operational  research 
tools,  such  that  managers  will  embrace  their  use,  is  the 
problem  that  needs  to  be  resolved  in  order  to  achieve  the 
goal.  One  such  tool,  Multiobjecti ve  Decision  Analysis,  has 
not  yet  been  applied  to  the  microcomputer  environment. 

This  research  involves  implementation  of  the  con¬ 
straint  and  weighting  mul ti object i ve  analysis  techniques 
(3:211).  The  program  is  designed  and  implemented  in  such  a 
way  to  also  serve  as  an  instructional  aid  to  students  and/or 
inexperienced  users.  Hardware,  software,  and  user  charac¬ 
teristics  were  considered  in  order  to  maximize  the  utility 
of  the  resultant  package.  Special  emphasis  was  placed  on 
program  portability  and  user  friendliness.  Structured 
design  techniques  were  employed  to  insure  that  the  end 
product  is  maintainable. 

Research  Question 

Consi derati on  of  the  problem  described  above  leads  to 
the  fallowing  questions:  Can  a  multiobjecti ve  decision 
analysis  package  be  successfully  implemented  on  a  personal 
computer?  Would  such  an  implementation  be  usable  in  a  prob¬ 
lem  solving  environment  without  operations  research  staff 
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and/or  data  processing  staff  support?  Mould  such  an  appli¬ 
cation  improve  the  manager’s  decision  making  ability?  With 
these  questions  in  mind,  the  overall  objective  of  this 
research  was  to  develop  a  multiobjective  decision  analysis 
package  for  a  personal  computer.  Specific  subobjectives 
were: 

1)  To  maximize  program  portability  through 
proper  hardware  selection,  implementation 
language  selection,  and  program  design. 

2)  To  maximize  program  acceptance  to  users 
regardless  of  their  expertise  through  a 
"friendly"  user  interface. 

3)  To  maximize  program  mai ntai nabi 1 i ty  by 
utilizing  a  top-down  design  methodology  and 
by  providing  complete  user  and  programmer 
documentat i on . 

Presentation  Outline 

Section  II  describes  the  current  state-of-the-art  for 
the  primary  research  question,  namely:  Can  multiobjective 
decision  techniques  be  successfully  applied  to  a  microcom¬ 
puter?  Section  III  provides  a  backr -  tund  description  for 
the  techniques  that  were  implemented.  The  important  program 
development  considerations  are  presented  in  section  IV,  with 
a  specific  description  of  the  implementation  provided  in 
section  V.  Finally,  research  conclusions  and  recommenda¬ 
tions  appear  in  section  VI.  Program  documentation  consist¬ 
ing  of  a  user’s  manual  and  programmer’s  manual  appear  as 
Appendix  A  and  Appendix  B  respectively. 


1 1  Li terature  Revi ew 

In  order  to  successfully  complete  this  research,  a 
literature  review  of  the  pertinent  areas  was  performed  and 
is  summarized  below. 

Personal  Computer  Applicability  to  Operations  Research 

A  number  of  authors  have  recognized  the  mi crocomputer ’ s 
appl i cabi 1 i ty  to  operations  research  problems  (4,  11,  16, 
18,  20,  30).  In  Hollock’s  1981  article  (18),  the  increasing 
importance  that  personal  computers  are  expected  to  play  in 
operations  research  is  sighted,  along  with  a  description  of 
a  specific  successful  application  in  the  steel  industry. 
Douglas  also  emphasizes  the  increasing  influence  of  personal 
computers  in  his  article  (11).  However,  he  is  particularly 
enthusiastic  about  the  fact  that  personal  computers  provide 
the  means  to  bring  the  problem  solving  process  closer  to  the 
client  (11:253).  In  addition,  he  points  out  the  potential 
to  use  color  and/or  graphics  in  improving  operational  re¬ 
search’s  ability  to  describe  problem  solutions  (11:254).  In 
Geoffrion  (16),  the  author  describes  the  MS/OR  field  as 
consisting  of  two  separate  domains:  The  world  of  action  and 
affairs,  epitomized  by  line  managers?  and,  the  world  of 
ideas,  epitomized  by  academi cs ( 1 6: 1 1 ) .  The  author  describes 
what  he  preceives  to  be  a  considerable  rift  between  the  two 
domains,  and  cites  the  personal  computer  as  the  factor  most 
likely  to  eliminate  the  differences  between  the  two  (16:14). 
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The  articles  described  above  justify  the  need  for 
microcomputer  applications  to  operations  research.  Other 
works  begin  by  assuming  that  this  need  exists,  and  then  pro¬ 
ceed  to  describe  the  wide  range  of  hardware  conf igurations 
and  options  available  for  application.  Two  articles  and  one 
book  in  particular,  define  what  microcomputers  are,  and  then 
compare/contrast  the  various  hardware  conf igurations  (5,  7, 
27).  In  an  article  by  Ranyard  (27),  the  author  describes 
the  character i sti cs  that  are  desirable  in  personal  computers 
which  are  to  be  applied  to  operations  research  problems 
(27:281).  He  then  describes  four  companies'  experiences 
with  personal  computers  in  their  operations  research  depart¬ 
ments.  The  computers  compared  were:  Cromemco,  PETS,  TEI 
PT212,  and  PRIME  (27:291).  These  computers  are  all  similar 
and  are  typical  of  many  of  today’s  average  microcomputers 
(i.e.  64K  of  memory,  0.5  Megabyte  disc  storage,  8  or  16  bit 
central  processor,  printer,  and  video  display).  The 
companies  met  with  varying  levels  of  success,  however,  in 
general ,  they  were  all  satisfied  with  the  various  systems. 
The  article  by  Clementson  and  Clewett  (7),  and  the  book  by 
Cassell  (5),  describe  available  microcomputer  features  in 
more  general ,  less  operations  research  specific  terms. 

Two  thesis  (10,  12)  that  demonstrate  linear  programming 
applications  to  personal  computers  have  been  reviewed.  Al¬ 
though  both  programs  perform  principally  the  same  function, 
they  differ  considerably  in  implementation  and  ease  of  use. 


In  the  thesis  by  Fraley  and  Kem  (12),  a  FORTRAN  implementa¬ 


tion  -for  an  APPLE  11+  computer  is  demonstrated.  The  program 
provides  relatively  rapid  response  and  a  comprehensive 
linear  programming  package,  but  is  somewhat  difficult  to  use 
because  of  limitations  inherent  in  the  PASCAL  operating 
system  (which  is  required  in  order  to  run  FORTRAN  on  an 
APPLE  computer).  Conte,  in  his  1979  research,  demonstrated 
a  BASIC  implementation  on  an  APPLE  11+  computer.  The 
program  provides  a  basic  linear  programming  capability  but 
is  somewhat  slow  in  response  due  to  the  speed  limitations 
inherent  in  interpretive  BASIC.  These  two  different 
implementations  of  a  similar  package  demonstrate  the  kinds 
of  tradeoffs  necessary  when  considering  a  microcomputer 
implementation. 

The  special  design  consi derati ons  for  programs  that  are 
to  be  implemented  on  microcomputers  are  documented  in  a  book 
by  Freedman  and  Evans  (13).  Emphasis  is  given  to  a 
systematic  approach  that  begins  with  the  system’s  functional 
specification  and  proceeds  through  system  tests.  Although 
not  directly  oriented  towards  operations  research  type 
problems,  the  Freedman  book  defines  those  steps  necessary  to 
insure  successful  mi crocomputer  program  implementation. 

Mul tiob iecti ve  Decision  Analysis 


This  phase  of  the  literature  review  involved  investi¬ 
gating  techniques  appropriate  for  implementation  in  this 


research.  One  -fairly  recent  article  by  Cohon  and  Marks  (8) 
provides  a  comprehensive  review  o-f  existing  mul  t  i  ob  j  ect  i  ve 
analysis  techniques.  In  order  to  evaluate  the  various 
techniques,  the  authors  established  three  different 
evaluation  criteria: 

a)  computational  efficiency, 

b)  explicitness  of  tradeoffs  among  objectives,  and 

c)  the  amount  of  information  generated  for 
decision  making  (8:200). 

The  article  classified  the  various  techniques  into  three 
categories: 

a)  generation  techniques  (including  the  weighting 
and  constraint  methods), 

b)  techniques  which  rely  on  prior  articulation 
of  preferences  (including  goal  programmi ng ) , 
and , 

c)  techniques  which  rely  on  progressive 
articulation  of  preferences  (including  the 
iterative  weighting  method)  (8:210). 

The  authors  found  that  the  comparison  of  techniques  was 
itself  a  multiobjective  problem  with  three  criteria.  As 
might  be  expected,  computational  efficiency  suffers  as  the 
amount  of  information  generated  increases  (8:217).  The 
authors  concluded  that  the  generating  techniques  were  most 
desirable  when  they  could  be  afforded  in  terms  of  computa¬ 
tional  efficiency.  However,  they  felt  that  when  there  are 
four  or  more  objectives,  a  technique  that  limits  the  size  of 


the  -feasible  region  should  be  used  (8:219). 

This  research  does  -focus  on  the  generating  techniques, 
speci -f  ical  ly  the  weighting  and  constraint  techniques.  It 
leaves  the  other  techniques  -for  -future  program  enhancement. 

The  theoretical  and  mathematical  basis  for  the  various 
techniques  described  above  are  provided  in  several  multi - 
objective  analysis  textbooks.  One  excellent  example  is  a 
text  by  Cohon  (9) ,  which  presents  most  of  the  data  necessary 
for  computer  implementation  of  the  various  operations 
research  algorithms.  This  background  data  is  summarized  in 
the  following  section. 
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Techniques  -for  solving  multi  objective  problems  can  not 
be  characterized  as  new,  since  Kuhn  and  Tucker  were  credited 
with  their  discovery  in  1951  (8:208).  However,  as  stated 
earlier,  the  problem  lies  in  making  these  techniques  avail¬ 
able,  in  an  easy  to  use  -fashion,  to  the  decision  maker.  Two 
techniques,  the  weighting  and  constraint  techniques,  have 
been  implemeted  on  a  personal  computer  as  part  o-f  this 
research.  The  remainder  o-f  this  section  is  devoted  to 
describing  these  techniques.  However,  before  continuing,  a 
simple  hypothetical  multi  objective  problem  is  presented  to 
help  clarify  the  description  of  the  techniques. 

Example  Mul t i ob i ect i ve  Problem 

Suppose  some  procurement  office  has  been  tasked  with 
deciding  how  many  each  of  two  types  of  aircraft  to  obtain. 
The  aircraft  types  are  designated  XI  and  X2.  Both  aircraft 
are  fighters  offering  some  bombing  capability.  The  procure¬ 
ment  office  is  faced  with  two  objectives: 

a)  to  maximize  bombing  capability,  and 

b)  to  maximize  fighter  capability. 

It  has  been  determined  that  aircraft  XI  is  more 
effective  as  a  bomber  while  aircraft  X2  is  a  better  fighter, 
and  the  following  relationships  have  been  established: 


bomber  capability  =  2  times  the  number  of  XI  aircraft 

+  1  times  the  number  o-f  X2  aircraft  (1) 
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fighter  capability  =  1  times  the  number  of  XI  aircraft 

+  2  times  the  number  of  X2  aircraft  (2) 

More  formally,  in  this  problem  we  wish  to: 


MAXIMIZE: 

2  ( X 1 ) 

+  1 (X2) 

-bomber  capability— 

(3) 

MAXIMIZE: 

1  (XI) 

+  2 ( X2) 

-fighter  capability— 

(4) 

At  first 

gl ance, 

it  appears 

that  we  can  obtain  as 

high 

a  value  as  desired  for  both  bomber  and  fighter  capabilites 
simply  by  buying  large  numbers  of  aircraft.  Unfortunately 
this  type  of  solution  is  not  usually  practical  since 
resources  are  usually  scarce.  For  our  problem  we  will 
assume  that  the  manufacturer  of  XI  can  supply  no  more  than 
ten  aircraft  and  the  manufacturer  of  X2  can  supply  no  more 
than  eight  aircraft.  A  higher  authority  has  mandated  that 
no  more  than  a  total  of  12  aircraft  may  be  procurred.  These 
restrictions  serve  as  the  problem  constraints.  More 
formally  stated,  these  constraints  are: 


XI 

<=  10 

(XI  supply  limit) 

(5) 

X2 

<=  8 

(X2  supply  limit) 

(6) 

XI  +  X2 

<=  12 

(total  procurement  limit) 

(7) 

A  "non-negativity  constraint"  is  also  added  to  the  problem 
since  it  does  not  make  sense  to  procure  negative  numbers  of 
aircraft.  That  is: 


XI  and  X2  >=  0 


(non-negativity  constraint) 


(8) 


When  dealing  with  problems  with  only  'two  decision 
variables  (i.e.,  number  o-f  Xls  and  number  o-f  X2s)  it  is 
help-ful  to  use  graphs  to  define  the  area  of  acceptable 
solutions.  For  example.  Figure  1  is  a  graph  of  the  problem 
constraints.  The  shaded  region  represents  the  complete  set 
of  solutions  that  satisfy  all  of  the  constraints.  It  is 
referred  to  as  the  feasible  region. 

Unfortunately,  the  problem  involves  more  than  just 
selecting  a  legitimate  solution,  it  also  involves  selecting 
the  solution  which  optimizes  the  objectives.  With  our 
example  problem,  as  is  usually  the  case,  the  solution  which 
optimizes  each  of  the  objectives  is  not  the  same.  Instead, 
we  will  obtain  a  set  of  solutions  from  which  the  decision 
maker  will  make  his  selection.  Techniques  for  obtaining 
these  solutions  are  called  generating  techniques  (8:210)  and 
are  described  in  what  follows. 


Figure  1:  Problem  Feasible  Region 


The  Weighting  Technique 

In  single  objective  optimization  problems,  the  optimal 
solution  is  that  -feasible  solution  which  maximizes  (or  min¬ 
imizes)  the  objective.  This  solution  can  be  seen  graphical¬ 
ly  in  a  two  variable  problem  as  the  point  at  which  the 
objective  function  is  just  tangent  to  the  feasible  region. 
For  example,  suppose  for  our  problem  we  ignore  the  second 
objective  and  attempt  to  optimize  only  the  first.  As  the 
objective  function  assumes  higher  and  higher  values  of 
"bomber  capability"  we  see  in  Figure  2  that  at  a  value  of  22 
(ie  2X1  +  1X2  =  22)  the  function  is  just  tangent  to  the 
feasible  region  at  point  A.  At  higher  values  of  bombing 
capability  the  objective  function  does  not  intersect  the 
feasible  region.  That  is,  given  the  constraints,  we  can  not 
achieve  a  higher  bombing  capability  than  22. 


Figure  2:  Single  Objective  Solution 
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The  weighting  technique  involves  solving  a  series  of 
single  objective  problems.  In  each  problem  we  use  a  dif¬ 
ferent  objective  that  is  formed  by  multiplying  each  of  the 
original  objectives  by  a  weight  then  summing  them.  For  each 
solution  iteration,  we  use  a  different  set  of  weights.  With 
this  process  we  are  solving  a  different  objective  each  iter¬ 
ation.  The  solution  found  represents  the  optimal  solution 
for  that  aggregate  objective.  Each  solution  then  corre¬ 
sponds  to  differing  levels  of  importance  ascribed  to  each  of 
the  problem’s  objectives. 

For  the  present  example,  we  will  solve  the  problem  six 
times  using  objective  weights  ranging  from  one  to  zero  as 
f ol 1 ows: 


objective  weights 


i terat i on 

obj  1 

obj  2 

aggregate  objective 

1 

1.0 

0.0 

2.0X1  +  1.0X2 

2 

0.8 

0.2 

1.8X1  +  1.2X2 

3 

0.6 

0.4 

1.6X1  +  1.4X2 

4 

0.4 

0.6 

1.4X1  +  1.6X2 

5 

0.2 

0.8 

1.2X1  +  1.8X2 

6 

0.0 

1.0 

1.0X1  +  2.0X2 

As  we 

move  from 

iteration  number 

one  to  iteration 

number  six. 

the  slope 

of  the  aggregate 

objective  function 

slowly  changes.  This  reflects  the  fact  that  as  the  weights 
that  were  used  to  make  up  the  aggregate  objective  change, 
the  emphasis  for  that  iteration  solution  will  also  change. 
If  we  find  the  optimal  point  for  each  of  these  aggregate 
objective  functions  as  we  did  before,  by  locating  the  point 


on  the  highest  valued  objective  -function  that  is  just 
tangent  to  the  -feasible  region,  we  see  that  the  first  three 
iterations  result  in  optimal  solution  “A",  while  the  last 
three  iterations  are  optimal  at  point  “B".  This  result  is 
shown  graphically  in  Figures  3  and  4  respectively. 

Following  is  a  summary  of  the  objective  values  corre¬ 
sponding  to  the  above  solutions: 

objective  values 
solution  obj  1  obj  2 


"A" 

22 

14 

“B" 

16 

20 

Thus  we  can  see  that  as  expected,  we  can  improve  the 
value  of  objective  two,  but  only  at  the  expense  of  objective 
one  as  we  move  from  solution  A  to  solution  B.  For  each  of 
these  solutions,  no  point  offers  a  better  value  for  both  of 
the  objective  functions.  These  solutions  are  referred  to  as 
"non-domi nated  solutions." 

In  general,  the  weighting  technique  will  generate  only 
solutions  which  are  corner  points  of  the  problem’s  feasible 
region.  However,  all  of  the  points  between  the  extremes 
(points  A  and  B  in  this  case)  are  part  of  the  non-domi nated 
solution  set.  For  further  information  or  proof  of  this 
result,  the  reader  is  referred  to  the  text  on  the  subject  by 
Chankong  and  Haimes  (6). 

To  summarize,  the  weighting  technique  reduces  any 


multiobjective  problem  to  a  series  o-f  single  objective 
problems.  Each  o-f  these  generates  its  own  optimal  solution. 
Each  optimal  solution  corresponds  to  assigning  certain 
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importance  to  each  o-f  the  objectives  in  the  problem.  From 
the  complete  set  o-f  (non-domi nated )  solutions,  the  decision 
maker  will  select  that  solution  which  corresponds  to  the 
priorities  that  he  assigns  to  each  o-f  the  respective  objec¬ 
tives.  If  he  is  unsure  of  how  he  values  each  objective,  he 
can  select  from  the  non-dominated  solutions,  that  solution 
which  provides  the  best  acceptable  level  for  each  objective. 


The  Constraint  Technique 

The  constraint  technique  is  similar  to  the  weighting 
technique  in  that  it  reduces  the  multi  objective  problem  to  a 
series  of  single  objective  problems.  It  is  unlike  the 
weighting  technique  in  that  each  single  objective  problem 
uses  the  same  objective  with  different  constraints.  Specif¬ 
ically,  all  but  the  one  of  the  objective  functions  are  added 
to  the  problem  as  equality  constraints,  each  with  an 
assigned  "acceptable"  objective  limit.  It  is  this  objective 
limit  that  is  varied  for  each  iteration.  The  net  result  of 
adding  objectives  to  the  problem  as  constraints  is  to 
further  restrict  the  feasible  region. 

For  example,  in  the  previous  section  we  determined  that 
for  the  set  of  non-dominated  solutions,  the  value  of  the 
second  objective  ranged  from  14  to  20.  Suppose  we  determine 


that  a  fighter  capability  value  of  17  is  acceptable.  With 


the  constraint  technique  then,  the  problem  would  be  to  maxi¬ 
mize  the  bomber  capability  given  that  the  fighter  capability 
equals  17.  That  is,  we  have  added  the  following  constraint: 

XI  +  2X2  =  17  (objective  #2  limit)  (9) 

Since  this  is  an  equality  constraint,  the  feasible  region  is 
reduced  to  those  points  on  the  line  defined  by  equation  (9) 
that  are  within  the  original  feasible  region.  Graphically, 
the  new  feasible  region  is  shown  in  Figure  5  as  all  points 
on  the  line  between  points  “D11  and  "C" . 

Given  this  new  feasible  region,  the  optimal  value  of 
the  first  objective  occurs  when  it  intersects  point  "C". 
Thus  we  have  obtained  one  non— dominated  solution  via  the 
constraint  technique.  More  solutions  are  obtained  by 
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Figure  5:  Feasible  Region/Constraint  Technique 


iteratively  solving  the  problem  varying  only  the  limit  on 
the  objectives  that  now  serve  as  constraints. 

In  this  case,  i-F  we  vary  the  objective  limit  -from  14  to 
20  in  seven  steps  we  will  obtain  seven  different  non— 
dominated  solutions  as  follows: 


objective  #2 

objective  #1 

deci si on 

vari abl es 

limiting  value 

computed  value 

XI 

X2 

14 

22 

10 

2 

15 

21 

9 

3 

16 

20 

8 

4 

17 

19 

7 

5 

18 

18 

6 

6 

19 

17 

5 

7 

20 

16 

6 

8 

As  before,  we  see  that  we  can  achieve  an  improvement  in  one 
objective,  but  only  at  the  expense  of  the  other  objective. 

The  constraint  technique  has  the  advantage  that  it  will 
generate  more  than  just  corner  point  solutions  of  the  orig¬ 
inal  feasible  region.  This  technique  does  however  require 
some  prior  knowledge  of  the  range  that  the  objectives  can 
real istical 1 y  be  expected  to  assume.  That  is,  if  we  were  to 
set  the  level  of  objective  two  at  any  value  over  20,  we 
would  obtain  no  feasible  solutions.  Similarly,  setting 


objective 

two 

to 

any  value 

under 

14  would  result 

in  a 

solution 

with 

a 

subopti mal 

val  ue 

for  objective 

one. 

In  a 

sense,  all 

iterations  that 

set  the  objective 

two 

limit 

outside  of  the  14  to  20  range  are  wasted  since  they  will  not 
generate  a  non-domi nated  solution.  Further  information 
concerning  this  technique  can  be  found  in  the  text  by 
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package  required  a  care-ful  analysis  of  the  end  user,  the 
hardware,  and  the  support  software  environment  prior  to  the 
program  design  process.  This  section  describes  program 
consi derati ons  related  to  these  three  topics. 

User  Interface 

How  the  program  is  accepted  by  the  end  user  is  consid¬ 
ered  to  be  the  most  important  criterion  for  determining 

program  success.  Two  design  aspects  needed  to  be  addressed 

I 

in  order  to  insure  user  acceptance.  First,  it  was  felt  that 
the  system  must  increase  the  timeliness,  effectiveness,  and 
availability  of  information  (28:66);  and  second,  a  friendly 
interface  that  does  not  require  its  users  to  be  a  specialist 
in  either  operations  research  or  computer  science  was  deemed 
essential. 

I 

Systems  that  satisfy  the  first  goal  are  referred  to  as 

"quick  response  systems."  These  systems  offer  the  following 

advantages: 

I 

—  they  allow  managers  to  react  more  rapidly 

—  they  reduce  waste  in  the  use  of  resources 

I  —  they  permit  quick  follow-up  on  creative  ideas 

(28:67) . 


It  was  determined  that  the  quick  response  goal  would  be 
achieved  automatically  as  a  result  of  hosting  the  package  on 
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a  microcomputer.  The  result  would  be  a  software  package 
that  is  readily  available  on  the  managers  desk.  Its  use 
would  not  be  subject  to  the  data  processing  department’s 
schedul es. 

The  second  goal  of  a  user  -friendly  system  though  was 
not  as  easy  to  obtain.  User  -friendliness  in  computer 
systems  involves  much  more  than  easy  to  read  system  prompts 
(21:125).  It  requires  a  careful  analysis  of  the  end  users 
needs  and  character i sti cs  (29:125).  Throughout  this 
research,  seven  practical  steps  were  employed  to  help  insure 
the  development  of  a  truly  user  friendly  system. 

Minimum  worker  effort.  It  was  determined  that  the 
system  should  require  minimum  worker  effort  of  its  users 
(14:165).  Workers  should  be  required  to  perform  only  work 
that  is  absolutely  essential  and  can  not  be  performed  by  the 
system.  For  example,  in  this  system,  although  the  software 
is  only  capable  of  maximizing  objectives,  it  allows  users  to 
enter  objectives  to  be  minimized.  Rather  then  requiring  it 
of  the  user,  the  program  converts  these  objectives  (by 
multiplying  by  -1)  to  a  form  to  be  maximized.  All  displays 
indicate  the  data  in  the  form  as  entered.  The  fact  that  the 
data  had  been  internally  transformed  is  of  no  consequence  to 
the  user  and  is  kept  transparent  to  him. 

Another  technique  employed  to  minimize  worker  effort  is 
to  not  require  workers  to  repeat  work  done  in  the  past. 
This  is  accomplished  by  the  program  by  its  "remembering" 


problem  descriptions  and  by  offering  the  means  to  obtain 


problem  results  in  hardcopy  form.  In  addition,  the  user  is 
not  required  to  search  for  system  information  as  documenta¬ 
tion  concerning  every  system  prompt  is  available  on-line  as 
part  of  the  system’s  HELP  capability. 

Minimal  worker  memory.  System  acceptance  is  enhanced 
when  system  use  does  not  depend  on  excessive  use  of  the 
workers  memory  (14:165).  For  this  system,  users  are  not 
required  to  memorize  complex  command  strings  or  non-task 
related  terminology.  Rather  than  a  command  directed  pro¬ 
gram,  a  menu  of  options  is  given  to  the  user  for  selecting 
the  next  system  operation.  In  addition,  menus  are  organized 
in  a  hierarchical  fashion  so  that  only  the  applicable 
options  are  presented  at  each  point.  Furthermore,  all 
system  prompts  and  error  messages  are  complete  sentences  and 
do  not  utilize  computer  or  other  unfamiliar  terms.  Termi¬ 
nology  is  consistent  throughout  all  software  functions. 

Minimum  worker  frustration.  Systems  should  spare  the 
worker  frustrations  that  may  arise  from  a  delay  in  the 
accomplishment  of  a  task  (14:166).  In  this  system,  since  it 
is  run  on  a  dedicated  personal  computer,  there  is  no  delay 
from  step  to  step.  If  the  worker  is  interrupted,  the  system 
provides  the  means  for  the  user  to  review  his  work  prior  to 
the  interruption.  In  most  cases,  recovery  from  erroneous 
menu  responses  is  accomplished  with  one  keystroke.  Finally, 


menus  are  hierarchical ly  organized  so  that  users  do  not  have 


to  perform  or  explicitly  bypass  unnecessary  steps. 


Another  common  source  of  worker  frustration  arises  from 
systems  that  present  cryptic  error  messages  or  systems  that 
fail  from  actions  that  do  not  on  the  surface,  appear  to  be 
in  error.  For  example,  on  some  systems,  input  data  is  not 
subjected  to  range  checks.  In  these  cases,  users  may  input 
data  that  can  later  cause  an  overflow  (such  as  when  dividing 
by  zero).  User  friendly  systems  should  screen  input  data  to 
prevent  the  occurrence  of  nonsensical  conditions. 

Maximizing  Use  of  Habit  Patterns.  Systems  should  re¬ 
spond  to  the  human  tendency  to  form  long  and  short— term 
patterns  of  action  (14:166).  Systems  should  take  advantage 
of  "muscle  memory"  by  consistently  using  the  same  keys  for 
specific  functions,  by  consistently  placing  similar  informa¬ 
tion  on  display  screens  in  the  same  position,  and  by  con¬ 
sistent  design  of  screen  and  hardcopy  formats.  The  worker 
should  be  able  to  accomplish  tasks  using  a  single  consistent 
approach  and  terminology  for  all  program  functions. 

Prompt  Problem  Notification.  The  worker  should  be 
notified  of  a  problem  as  soon  as  it  is  detected  and  be  noti¬ 
fied  of  potential  problems,  wherever  possible,  in  advance  of 
their  occurrence  (14:166).  As  mentioned  earlier,  careful 
screening  of  inputs  at  the  time  of  entry  rather  than  at  the 
time  of  use  can  prevent  the  compounding  of  error  conditions. 
Following  user  input  errors,  the  user  is  given  the  opportu¬ 
nity  to  correct  the  problem,  and  control  is  returned  to  the 
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point  of  interruption.  User  inputs  are  automat i cal  1 y  saved 
to  disk  to  prevent  inadvertent  loss  due  to  inexperience 
and/or  external  circumstances. 

Maximum  worker  control  of  tasks.  The  worker  should 
control  the  -flow  and  sequence  o-f  work  to  the  extent  possible 
where  there  are  no  sequence-dependent  activities  (14:166). 
The  worker  should  be  able  to  modify  the  priorities  of  pro¬ 
cessing  by  the  computer.  Finally,  the  user  should  be  able 
to  store  and  retrieve  information  in  a  consistent  manner. 
In  this  implementation  of  multiobjective  decision  analysis, 
users  are  free  to  define  and/or  solve  problems  in  any 
sequence  with  the  individual  problem  files  freely  inter 
changable  from  disk.  The  presentation  order  and  extent  of 
most  system  outputs  are  totally  user  specified  as  is  the 
order  of  utilization  of  the  solution  techniques. 

Input /Output  Design  Consi derati ons.  Several  items 
related  to  the  input /output  of  system  information  should  be 
considered  to  maximize  system  user  friendliness.  First,  all 
system  outputs  including  questions,  menus,  error  messages, 
displays  and  help  information  should  be  designed  in  an  at¬ 
tractive  way.  This  involves  use  of  the  entire  screen  width, 
usage  of  both  upper  and  lower  case  characters,  and  the  wise 
usage  of  spacing.  All  of  these  factors  contribute  to  the 
ease  with  which  outputs  are  interpreted.  Also,  care  should 
be  taken  to  prevent  data  from  "scrolling  off"  the  screen 
before  the  user  has  had  an  opportunity  to  interpret  the 
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in-formation.  That  is,  most  outputs  should  be  designed  with 


a  screen  size  (24  lines  by  80  characters)  in  mind.  For 
displays  requiring  more  space,  the  user  should  be  in  control 
o-f  when  the  display  should  continue  after  each  "page".  In 
addition  to  being  neat  and  orderly,  both  screen  and  hardcopy 
displays  should  be  concise  and  contain  only  information 
pertinent  to  the  present  task. 

,  Hardware 

The  multitude  of  available  mi croprocessors  (over  250 
as  of  late  1983)  and  the  frequency  with  which  new  ones  are 
I  introduced  makes  it  virtually  impossible  to  be  up  to  date  on 

all  of  them  (5:197).  Yet,  hardware  selection  is  a  critical 
element  of  any  successful  mi crocomputer  application. 

!  Since  one  of  the  primary  goals  of  this  research  is  to 

make  multiobjective  techniques  universally  available,  it  was 
decided  that  the  implementation  should  necessarily  involve  a 
I  popular  and  common  hardware  configuration.  Software  which 

is  developed  on  a  system  with  limited  availability  to  the 
target  users  will  not  be  used  extensively  (12:47).  Select- 
I  ing  a  readily  avai.able  system  does  not  guarantee  that  the 

software  package  will  be  easily  transportabl e.  It  is  also 
essential  to  consider  system  modifications  and  required 
I  peripherals  of  the  target  system  (12:47).  If  these  modifi¬ 
cations  or  added  equipment  are  unique  to  the  development 

system,  widespread  use  of  the  software  will  be  limited. 

*  Thus  it  was  decided  that  the  target  system  should  also  be  a 


basic  system,  that  is,  require  only  the  standard  assortment 
of  peripherals. 

Even  with  these  two  restrictions  (i.e.  commonly  avail¬ 
able  system  and  no  unique  peripherals  required)  there  is  a 
wide  range  of  potential  target  systems.  An  examination  of 
the  general  characteristics  of  potential  host  micro¬ 
processors  was  necessary  prior  to  target  system  selection. 

Size.  Mi croprocessors  are  commercially  available  in 
the  following  sizes:  1,  2,  4,  8,  12,  16,  and  32  bits.  The 
term  size  refers  to  the  number  of  bits  in  the  microproces¬ 
sor’s  internal  registers  (5:212).  Operational ly,  size  de¬ 
termines  the  extent  of  the  machine’s  instruction  set  and  its 
addressing  capability.  Eight  and  sixteen  bit  microproces¬ 
sors  are  the  most  common  and  both  possess  the  addressing 
range  required  for  the  problem  at  hand  (i.e.  65,536  or  more 
words) . 

Speed.  The  speed  of  a  mi croprocessor  is  determined 
by  how  fast  it  executes  programmed  instructions.  Speed  is 
greatly  affected  by  the  type  of  instruction  (i.e.  division, 
shift,  multiplication,  store,  increment,  etc.).  Thus  for 
most  microprocessors  speed  is  specified  as  a  range  of  speeds 
for  the  complete  instruction  set.  For  eight-bit  microproc¬ 
essors,  instruction  speeds  range  from  0.7  to  37.5  micro¬ 
seconds  (5:224).  Because  of  the  complexity  of  the  multi¬ 
objective  decision  problem,  and  because  systems  with  a  slow 
response  time  are  not  considered  user  friendly,  it  was 
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determined  that  user  acceptance  would  be  enhanced  by 


utilizing  a  relatively  fast  mi croprocessor . 

Other  Character i st i cs.  There  are  several  other 
characteristics  of  mi croprocessors  including  semi-conductor 
technology,  ways  in  which  the  mi croprocessor  is  interfaced 
to  memory  and  input/output  subsystems,  internal  organiza¬ 
tion,  addressing  modes,  instruction  set,  and  the  degree  to 
which  the  mi croprocessor  supports  other  devices  (5:211). 
For  the  purpose  of  this  research,  these  character i st i cs  were 
not  explicitly  considered  since  the  target  system  will  be  a 
complete  system  in  a  standard  configuration.  The  internal 
character i st i cs  of  the  mi croprocessor  will  be  transparent  to 
the  end  user. 

Summarizing,  we  have  the  following  requirements  for  the 
mi croprocessor  on  which  the  mul t i ob j ect i ve  package  was  to  be 
i mpl emented : 

—  commonly  available  system 

—  requires  no  unique  periphreal  equipment 

—  relatively  fast 

—  capable  of  addressing  at  least  64K  words 

—  capable  of  supporting  a  high  level  language 

Support  Software  Environment 

The  support  software  environment  refers  to  all  computer 
software  required  for  program  development.  It  includes, 
compilers,  disk  operating  systems,  data  base  management 


systems,  and  etc.  For  this  application,  the  disk  operating 
system  is  taken  as  a  given  once  the  hardware  configuration 
is  selected  since  this  type  of  software  is  highly  machine 
dependent,  and  not  portable  from  microprocessor  to  micro¬ 
processor.  Also,  all  data  mani pul ati on/organi zati on  will  be 
handled  strictly  within  the  mul t i ob j ect i ve  decision  analysis 
package  itself  such  that  no  external  data  base  management 
system  will  be  required.  Therefore,  the  only  decision  to  be 
made  concerning  the  support  software  environment  involves 
selection  of  the  programming  language  for  implementation. 
Once  the  programming  language  is  selected,  the  language 
support  tools  including  linkage  editors  and  loaders  will  be 
given  since  these  packages  are  generally  interdependent. 

Machine  language  programming  is  the  most  efficient  in 
terms  of  program  size  and  execution  speed  (15:14).  However, 
because  of  the  desire  for  program  portability,  a  machine  or 
assembly  1 anguage  implementation  was  not  considered,  since 
such  implementations  are  not  at  all  portable  to  micro¬ 
processors  other  then  the  original  host  system. 

Of  the  high-level  languages,  BASIC  was  once  the  only 
option  for  microprocessors  (12:48).  Today  however,  many 
languages  including  FORTRAN,  COBOL,  Pascal,  APL,  and  ADA  are 
in  common  use.  Because  of  the  desire  to  maximize  program 
usage  through  portability,  it  was  decided  that  only  the  most 
widely  used  programming  1 anguages  would  be  considered.  This 
limited  the  selection  to  BASIC,  FORTRAN,  and  Pascal  (12:48). 


BASIC.  Most  personal  computers  come  "equipped"  with 
the  BASIC  programming  language.  The  BASIC  language  was 
first  developed  as  any  easy  to  learn  and  use  programming 
language.  It  was  not  designed  for  running  very  large  or 
very  complex  programs  where  program  speed  is  important. 
BASIC  is  called  an  interpretive  language  since  the  computer 
interprets  each  instruction  it  encounters  every  time  the 
program  is  executed.  Although  interpretive  BASIC  programs 
require  less  memory  than  most  comparable  compiled  programs, 
they  pay  a  considerable  penalty  in  terms  of  execution  time. 
This  time  penalty  can  be  overcome  by  utilizing  compiled 
BASIC,  several  implementations  of  which  are  now  available 
for  different  microprocessors. 

Advantages.  The  primary  advantage  to  be  gained 
by  using  BASIC  for  program  implementation  is  the  languages 
widespread  use.  Virtually  all  popular  microprocessors 
support  BASIC. 

Pi sadvantaaes.  Several  programming  functions 
that  are  necessary  for  the  multiobjective  decision  analysis 
package  are  not  implemented  consistently  between  the  various 
BASIC  language  versions.  Specifically,  disk  file  manipula¬ 
tions  and  report  (output)  formatting  functions  can  vary 
greatly  from  machine  to  machine.  This  implies  that  a 
significant  recoding  effort  would  be  required  in  order  to 
rehost  the  package  to  some  different  computer. 

Pascal .  Pascal  was  developed  in  the  early  1970s  and 


has  proven  to  be  a  powerful  and  popular  high  level  language 
(12:49).  It  is  a  compiled  language  and  thus  does  not  suffer 
the  time  penalties  of  interpretive  BASIC. 

Advantages.  Pascal  provides  an  extensive  over — 
lay  capability  that  allows  for  the  implementation  and  execu¬ 
tion  of  large  programs  (12:50).  In  addition,  the  widespread 
usage  and  implementation  of  Pascal  allows  for  increased 
potential  for  program  portability. 

Pi sadvantages.  The  Pascal  programming  language 
does  not  possess  extensive  output  formatting  capabilities 
(12:50).  This  shortcoming  complicates  the  programming  task 
when,  as  is  the  case  with  the  multiobjective  decision 
analysis  package,  carefully  formatted  outputs  are  desired. 

FORTRAN.  FORTRAN  (FORmula  TRANsl ator )  is  the  most 
widely  used  high  level  language  within  the  scientific  pro¬ 
gramming  community.  It  was  developed,  and  first  introduced 
in  the  early  1950s  by  IBM  (12:50).  Like  Pascal,  FORTRAN 
does  not  suffer  the  time  penalties  inherent  in  interpretive 
BASIC.  Because  of  FORTRANs  widespread  use,  there  have  been 
two  attempts  to  standardize  the  language  (12:50).  The 
latest  standardization  effort  took  place  from  1970  to  1977 
and  resulted  in  the  language  version  that  is  available  today 
on  most  mi crocomputer s. 

Advantages.  The  widespread  usage  of  FORTRAN 
enhances  maintainability  and  encourages  portability.  In 
addition,  FORTRAN  provides  extensive  report  formatting 


capabilities  <12:50). 

Pi sadvantaoes.  Except  for  the  newest  language 
extensions  which  are  not  yet  common  to  all  microprocessor 
versions  of  FORTRAN,  the  language  lacks  the  programming  con¬ 
structs  that  facilitate  a  structured  programming  approach. 
As  a  result,  program  maintainability  suffers. 


35 


V  I  mol ementation  Descri pt i on 


The  user,  hardware,  and  support  software  considerations 
described  in  the  previous  chapter  have  been  analyzed  for  the 
purpose  of  establishing  the  target  system  configuration  for 
this  research.  The  primary  selection  criteria  was  to  estab¬ 
lish  the  system  which  offers  the  highest  probability  of 
achieving  the  research  objectives  as  stated  in  chapter  I. 
The  purpose  of  this  chapter  is  to  describe  the  program 
implementation. 

Hardware. 

The  hardware  selection  process  was  limited  to  8-bit 
mi croprocessors  for  several  reason.  First,  8-bit  micropro¬ 
cessors  are  currently  more  common  in  personal  computers  then 
the  16  or  32-bit  size.  Second,  it  was  decided  that  should  a 
rehost  to  a  different  size  microprocessor  become  desirable 
at  a  later  date,  the  process  of  switching  to  a  more  powerful 
unit  would  be  easier  than  having  to  downscale  the  program 
for  hosting  on  a  smaller  unit.  Finally,  it  was  determined 
that  an  8-bit  mi croprocessor  would  be  sufficient  for  the 
task. 

Of  the  available  S-bit  microprocessors,  the  Z80  was 
selected  because  it  is  one  of  the  most  commonly  used  8-bit 
mi croprocessors  and  because  it  is  one  of  the  fastest.  Many 
of  today’s  most  popular  personal  computers  utilize  the  Z80 
or  are  directly  compatable  with  it. 
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*  g I DEO  DISPLAY  SCREEN 


Figure  6:  System  Configuration 

The  program  itself  was  developed  on  an  Apple  11+ 
computer  equipped  with  the  Z80  "softcard"  by  Microsoft.  The 
program  is  designed  to  run  utilizing  a  "standard"  personal 
computer  configuration  as  shown  in  Figure  6.  The  program 
does  utilize  a  full  80-character  screen  width  thus,  Apple 
users  need  a  special  video  interface  (such  as  the  Videx 
Videoterm)  providing  that  capability  together  with  a  Z80 
softcard. 

The  standard  configuration  (Figure  6),  includes  a 
printer  which  is  listed  as  optional.  This  is  true  in  the 
sense  that  the  program  will  run  without  one,  however,  such 
usage  is  discouraged  since  problem  results  are  usually 
lengthy  and  difficult  to  assimilate  from  just  the  video 


display  screen. 


It  should  also  be  noted  that  although  the  program  was 
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developed  on  an  Apple  computer,  the  implementation  does  not 
utilize  any  Apple  unique  -features.  In  fact,  the  object  code 
will  run  on  any  Z80  based  computer  without  modification. 

Support  Software 

As  mentioned  in  chapter  IV  much  of  the  system’s  support 
software  environment  is  given  once  the  hardware  configura¬ 
tion  have  been  selected.  The  selection  of  the  Z80  micropro¬ 
cessor  as  implemented  via  the  Apple  11+  Softcard  dictates 
the  usage  of  the  CP/M  operating  system  for  program  develop¬ 
ment  and  operational  disk  input/output  requi rements. 

The  Z80  microprocessor  and  the  CP/M  operating  system 
support  all  of  the  languages  discussed  in  chapter  IV.  None¬ 
theless,  FORTRAN  was  singled  out  as  the  appropriate  choice 
mainly  because  of  its  universal  portability  and  extensive 
report  formatting  capabilities. 

It  should  be  stressed,  that  as  with  the  hardware,  this 
program  utilizes  no  FORTRAN  or  other  software  capabilities 
that  are  unique  or  specific  to  the  Apple  11+  computer.  In 
fact,  the  version  of  FORTRAN  that  was  used  (Microsoft’s 
FORTRAN-80)  is  based  on  the  American  National  Standard 
(ANSI)  FORTRAN  language  as  described  in  ANSI  document 
X3. 9-1966  which  was  approved  on  March  7,  1966  (22:7). 
(FORTRAN-80  includes  a  few  extensions  to  the  language,  all 
of  which  are  part  of  the  second  standardi zati on  effort  which 


was  concluded  in  1977.) 


In  short,  the  mul ti ob jecti ve  decision  analysis  package 
source  code  can  be  compiled  and  rehosted  on  any  personal 
computer  that  can  support  FORTRAN  and  that  satisfies  the 
configuration  requirements  as  specified  in  Figure  6. 

Program  Description 

The  multiobjective  decision  analysis  package  (hereafter 
referred  to  as  Personal  Computer  Aided  Decision  Analysis  — 
PCADA)  was  implemented  using  the  hardware  and  support  soft¬ 
ware  environment  as  described  above.  The  program's  purpose 
is  to  allow  users  to  solve  mul ti object i ve  decision  problems 
using  either  the  weighting  or  constraint  techniques.  The 
PCADA  package  is  subject  to  the  following  limitations: 

—  4  or  less  objectives 

—  10  or  less  constraints 

—  10  or  less  decision  variables. 

Although  designed  for  mul ti objective  problems,  PCADA  will 
also  handle  and  solve  single  objective  problems,  using  the 
same  software  functions. 

The  PCADA  package  consists  of  a  main  program  and  23 
subroutines.  A  total  of  3,424  lines  of  FORTRAN  code  was 
generated  to  accomplish  the  task.  The  program  was  written 
in  a  structured  (within  the  limitations  inherent  in  FORTRAN, 
see  chapter  IV)  and  modular  fashion.  The  subroutines  range 
from  51  to  366  lines  in  length  with  the  majority  being  under 
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Figure  7:  PCADA  Functional  Organization 


125  lines. 

Although  a  number  of  the  program's  subroutines  serve  as 
utilities  that  perform  repetitious  program  functions  (such 
as  reading  the  user’s  input)  at  all  levels  of  the  system, 
the  PCADA  package  is  best  described  as  consisting  of  three 
primary  functions.  The  functional  organization  of  the 
program  is  shown  graphically  in  Figure  7. 

Obtain  Problem  Description.  The  first  program  func¬ 
tion  is  concerned  with  obtaining  a  problem  description  in 
the  appropriate  format  in  preparation  for  problem  solution. 
The  system  offers  two  methods  for  obtaining  a  problem  de¬ 
scription.  First,  users  may  enter  their  problem  as  prompted 
by  the  PCADA  System;  and  second,  users  may  request  the 
system  to  obtain  the  problem  description  from  disk.  New 


problems  must  be  entered  into  the  system  -following  the  first 
method.  Once  entered  though,  they  are  automatically  saved 
to  disk  for  future  reference. 

Included  in  this  function  is  a  comprehensive  capability 
to  modify  existing  problem  descriptions.  The  following 
modification  options  are  available: 

—  add/delete  constraint 

—  add/delete  objective  function 

—  add/delete  decision  variable 

—  edit  constraint  coefficients 

—  edit  constraint  right  hand  side 

—  edit  objective  coefficients. 

As  with  new  problem  descriptions,  problems  are  automati cal  1 y 
saved  to  disk  when  they  are  modified. 

Solve  the  Problem.  The  second  program  function  is  to 
solve  the  problem.  Both  the  weighting  and  constraint 
techniques  are  offered.  This  function  is  designed  to  allow 
an  iterative  approach.  That  is,  users  who  are  unsure  of 
solution  ranges  may  wish  to  initially  run  the  problem  using 
the  weighting  technique  over  a  large  range  of  weights.  This 
solution  may  indicate  the  need  for  a  "finer"  solution  using 
a  smaller  weight  increment.  Instead,  the  user  may  wish  to 
examine  the  results  using  one  specific  (user  defined)  set  of 
weights.  A1 ternat i vel y ,  once  the  user  determines  the 
legitimate  range  that  the  objectives  may  assume  by  using  the 


weighting  techniques  he  may  wish  to  turn  to  the  constraint 
technique  to  locate  other  than  just  corner — point  solutions. 
The  user  determines  the  level  of  detail  for  both  techniques 
by  speci-fying  the  weight  or  constraint  increments  to  any 
desired  value. 

In  short,  the  user  is  free  to  thoroughly  investigate 
the  problem  solution  without  being  required  to  redefine  the 
problem.  Alternatively  he  is  free  to  modify  the  problem 
following  each  iteration  in  order  to  examine  solution 
impacts  due  to  changing  conditions. 

Presentation  of  Solutions.  The  third  and  final  pro¬ 
gram  function  is  designed  to  present  the  problem  solutions 
to  users,  as  needed,  in  an  easy-to-read  format.  Two  types 
of  solution  displays  are  available.  The  first  is  simply  a 
summary  of  the  objective  values  correspond! ng  to  each  non- 
dominated  solution.  The  second  is  a  detailed  summary  of 
each  solution  including  objective  values,  objective  weights 
(if  applicable)  and  decision  variable  values.  For  all 
solution  displays,  the  user  is  given  the  option  of  receiving 
results  on  the  video  display  screen  or  in  hardcopy  form  on 
the  printer. 

As  with  the  problem  solution  function,  the  user  is  free 
to  iterate  on  the  solution  presentation  options.  For  exam¬ 
ple,  users  may  first  wish  to  review  the  objective  summary  on 
the  display  screen  and  then  examine  some  or  all  of  the 
solutions  in  detail  using  the  screen,  printer  or  both. 
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User  Interface. 


The  program  uses  a  friendly  user-interface  as  described 
in  chapter  IV,  The  following  user  friendly  features  are 
included: 


—  Online  system  documentation  is  available  concerning 
any  question  or  prompt  simply  by  entering  “HELP"  or 

n  9  ii 


—  Presentation  of  a  display  of  the  current  problem  at 
any  time  simply  by  entering  "e"  (or  "SP"  to  obtain 
a  hardcopy  printout  of  the  problem). 

—  All  system  outputs  including  prompts,  menus,  help 
messages,  error  messages,  and  solution  displays  are 
neat,  easy  to  read  and  do  not  utilize  "computer 
terminology". 

—  System  control  of  program  outputs  to  prevent  loss 
of  data  due  to  “scrolling". 

—  Return  to  previous  menu  (i.e.  error  recovery)  in 
most  cases  by  simply  hitting  the  return  key. 

—  Minimize  user  effort  through  usage  of  a  menu 
directed  rather  than  command  directed  approach. 

—  Real  time  screening  of  user  inputs  to  help  prevent 
delayed  and/or  compounded  errors. 


Program  usage  is  described  in  detail  in  the  User's 
Manual  (Attachment  A)  and  program  implementation  is  detailed 
in  the  Programmer's  Manual  (Attachment  B) . 


Design  Innovations 

Even  though  mi crocomputer  capabilities  are  rapidly 
improving  and  becoming  increasingly  sophi sti cated,  the 
complexity  of  the  multiobjective  problem  has  demanded  the 
usage  of  innovative  techniques  in  order  to  achieve  the 
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approaches 


desired  goals.  Usage  of  traditional  programming 
in  mul t i ob j ect i ve  program  implementation,  even  with  maximum 
and  efficient  use  of  the  target  system  capabilities,  would 
still  leave  the  software  unworkable  or  at  best  unresponsive. 
Successful  mi crocomputer  implementation  of  complex  tech¬ 
niques  depends  on  both  technical  expertise  in  knowing  the 
computer  capabilities,  and  design  innovation. 

For  mul ti ob j ect i ve  decision  techniques,  the  limited 
mi croprocessor  speed  and  random  access  memory  (RAM)  capacity 
are  major  obstacles  to  successful  implementation.  As  a 
result,  a  number  of  design  tradeoffs  were  performed.  These 
tradeoffs  have  resulted  in  the  implementation  of  several 
innovative  and  non-tradi ti onal  techniques. 

Most  design  tradeoffs  involve  improving  program 
response  at  the  expense  of  program  size,  or  vice  versa. 
Since  both  of  these  resources  (i.e.  time  and  memory  space) 
were  at  a  premium  in  this  implementation,  the  first  design 
problem  was  to  identify  those  areas  where  response  time 
could  be  sacr .ticed,  without  detriment  to  the  system,  in 
order  to  gain  valuable  memory  space.  The  additional  memory 
space  could  then  be  applied  to  improving  response  time  in 
other  areas  where  such  improvements  are  deemed  necessary  to 
insure  user  acceptance.  The  goal  of  this  process  is  to 
match  system  resources  to  user  requi rements. 

Following  are  descriptions  of  several  of  the  major 
design  trades  and  the  resulting  design  innovations  that  were 


44 


performed  during  implementation  of  PCADA  software  package. 


Handling  of  Menu/Help  Data.  The  traditional  approach 
used  for  outputting  information  from  the  program  to  the  user 
involves  the  use  of  WRITE  or  PRINT  statements-  These  state¬ 
ments  reference  program  data  areas  that  contain  the  actual 
characters  that  are  to  be  output.  These  data  areas  are 
extremely  space  consuming.  Each  output  character  consumes 
exactly  one  byte.  When  the  i npl ementat i on  is  space  limited, 
the  programmer  may  be  tempted  to  eliminate  some  system 
oututs  and  abbreviate  others.  Both  of  these  actions  are 
undesirable  in  that  they  reduce  the  system’s  user 
f r i endl i ness. 

For  a  user  friendly  multiobjective  decision  package  a 
great  number  of  system  outputs  are  required.  At  a  minimum, 
outputs  must  be  descriptive  and  avoid  the  use  of  abbrevia¬ 
tions.  System  outputs  should  also  include  a  comprehensive 
HELP  capability  to  insure  user  acceptance. 

In  PCADA  over  50  menus  and  corresponding  help  displays 
are  used.  This  represents  over  20,000  characters  of  data. 
The  traditional  approach  would  then  utilize  20,000  bytes  of 
random  access  memory.  Since  PCADA  required  this  space  for 
other  program  capabi 1 i t i es,  an  analysis  of  alternative  menu 
handling  techniques  was  performed. 

It  was  decided  that  all  PCADA  menus  and  help  data  would 
be  stored  on  disk  and  loaded  individually  as  needed. 
Instead  of  20,000  bytes  of  RAM,  76S  bytes  is  used  for  this 


purpose.  The  cost  of  this  space  gain  was  an  increase  in 
response  time  since  each  new  menu  presentation  would  require 
a  disk  access. 

A  series  of  timing  tests  was  run  and  it  was  determined 
that  menus  stored  in  RAM  would  result  in  an  average  of  1 
second  response  time  while  disk  menus  require  an  average  of 
3.5  seconds  of  response  time.  This  2.5  second  penalty  was 
deemed  to  be  an  effective  trade  for  the  extra  space  since 
3.5  seconds  is  well  below  the  time  needed  for  the  user  to 
read  and  assimilate  the  menu.  However,  it  was  decided  that 
error  messages  should  appear  without  delay,  thus  they  are 
stored  in  RAM  and  generated  in  the  more  traditional  way. 
Using  th.s  new  menu  generation  approach,  excess  computer 
capacity  in  one  area  was  redirected  for  use  in  other  areas. 

Centralized  Input/Outout  Processing.  Along  the  same 
lines,  input  and  output  program  statements  are  among  the 
most  costly  in  terms  of  program  size.  Furthermore,  since 
the  need  for  input /output  operations  usually  is  widespread 
throughout  most  appl i cati ons,  these  types  of  statements  tend 
to  be  most  common.  It  was  decided  that  a  set  of  input/out¬ 
put  utilities  would  be  implemented  instead  of  using  a  READ 
or  WRITE  statement  wherever  needed.  Now,  when  a  program 
module  needs  to  ask  a  question  and  get  the  user’s  response, 
it  calls  the  appropriate  input/output  processor.  System 
READs  and  WRITES  are  isolated  to  one  centralized  location. 
This  technique  also  prevents  the  prol i f er at i on  of  range  and 
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error  checks  that  should  necessarily  accompany  all 
input/output  operations  -For  any  user  -friendly  system. 

Although  this  technique  has  resulted  in  a  considerable 
saving  of  random  access  memory  space,  it  has  introduced 
additional  overhead  in  terms  of  time  for  input/output  oper — 
at ions.  Now  instead  of  direct  READ  or  WRITES,  input /output 
operations  involve  4  or  5  extra  subroutine  calls.  This 
added  linkage  increases  execution  time  and  accordingly  pe¬ 
nalizes  response  time.  The  penalty  though  was  less  than  50 
milliseconds  per  response.  Since  menu  to  menu  response  was 
still  below  the  user’s  normal  readi ng/assi mi 1  at i on  time, 
this  time  impact  was  considered  to  be  a  worthwhile  trade. 

Linear  Programming  Package.  Unlike  menu  to  menu  re¬ 
sponse  time,  the  time  for  the  package  to  find  the  solution 
to  the  multi  objective  problem  was  excessive  and  needed 
to  be  reduced  to  make  the  package  successful.  Initial 
estimates  of  the  time  needed  for  each  linear  programming 
iteration  ranged  from  10  to  30  seconds,  depending  on  problem 
complexity.  Although  this  time  was  not  excessive,  the  cumu¬ 
lative  time  for  problems  requiring  many  iterations  would  be. 

To  reduce  the  execution  time,  the  linear  programming 
subroutine  was  redesigned.  The  new  version  employed  larger 
memory  work  areas  and  in  some  cases  redundant  sections  of 
code.  The  redundant  code  eliminated  the  overhead  associated 
with  establishing  the  linkage  to  use  common  code.  The 
overal 1  result  was  a  larger  subroutine,  but  a  faster  one. 
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now  running  -from  2  to  9  seconds  per  iteration.  Again,  a 
programming  technique  had  been  used  to  direct  the  computer’s 
resource  where  needed.  In  this  case  memory  had  been  used  to 
improve  execution  time. 


Per-formance  Data 

Because  system  response  time  was  considered  to  be  a 
major  factor  in  determining  user  acceptance,  it  was  given 
close  attention  throughout  the  development  process. 
Response  time  is  defined  as  the  time  between  the  user’s 
response  to  a  system  prompt  and  the  next  system  prompt. 
Since  PCADA  runs  on  a  dedicated  personal  computer,  response 
times  are  fixed.  They  are  not  affected  by  other  users 
and/or  system  loads  as  is  the  case  of  large  scale  computers. 

All  PCADA  menus  and  questions  are  stored  on  disk  and 
are  retrieved  in  real  time  when  needed.  For  a  typical  menu, 
ten  lines  in  length,  PCADA  response  times  average  3.5 
seconds.  Since  this  is  considerably  less  than  the  time 
needed  by  the  user  to  assmilate  the  question,  acceptable 
response  time  has  been  achieved.  Response  time  is  not 
significantly  influenced  by  menu  size. 

All  PCADA  error  messages  are  generated  internally,  and 
no  disk  access  is  required  for  their  presentati on.  As  a 
result,  error  messages  are  generated  instantly. 

Solution  times  are  heavily  influenced  by  the  problem’s 
complexity  (i.e.,  number  of  objectives,  number  of  decision 


var i abl es 


and  number  of  constraints) 


as  wel 1  as  the 


solution  parameters  (i.e.,  wei ght /constrai nt  increment). 
For  each  problem  iteration,  PCADA  requires  from  2  to  9 
seconds  to  compute  a  problem  solution.  Most  problems  will 
require  less  than  2  minutes  to  solve.  For  example,  PCADA 
solved  the  example  problem  presented  in  chapter  IV  using  the 
constraint  technique  with  7  steps  in  28  seconds.  However,  a 
complex  problem  with  4  objectives  using  a  weight  increment 
of  0.05  requires  almost  1.65  hours  to  complete.  While  run¬ 
ning,  PCADA  keeps  the  user  informed  of  its  progress. 

The  immediate  availability  of  the  microcomputer  based 
PCADA  package  is  considered  to  be  an  acceptable  tradeoff  for 
the  execution  delays  for  complex  problems.  Overhead  turn¬ 
around  time  associated  with  powerful  large  scale  computers 
is  often  measured  in  days. 

System  Outputs 

The  main  outputs  provided  by  the  PCADA  system  are  the 
problem  displays  and  the  solution  displays.  Using  the 
example  given  in  chapter  IV,  Figure  8  contains  the  system 
generated  problem  description. 

PCADA  offers  two  different  solution  displays.  The 
first  is  a  summary  of  problem  objective  values.  Figure  9 
contains  a  sample  of  such  a  display.  It  was  generated  using 
the  constraint  technique  on  the  example  problem  presented  in 
chapter  IV. 
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PROBLEM  NAME  =  EXAMPLE 


the 


-  OBJECTIVES  - 

1.  MAXIMIZE  BOMBER  =  +2.00x1  +1.00x2 

2.  MINIMIZE  FISHTER  =  +1.00x1  +2.00x2 


SUBJECT  TO  THE  FOLLOWING  CONSTRAINTS 


i.  nsuppLY: 

+1.00x1 

+0,00x2 

<= 

10.00 

2.  X2SUPPLY: 

+0.00x1 

+1.00x2 

<= 

8.00 

3.  ac-limit: 

+1.00x1 

+1.00x2 

<= 

12.00 

Figure  8:  Problem  Description  Display 


SUMMARY  OF  OBJECTIVE  VALUES  FOR  THE  NON-DOMINATED  SOLUTIONS 


OBJECTIVES  - 

SOLUTION  BOMBER  FIGHTER 


1 

22.0000 

14.0000 

2 

21.0000 

15.0000 

3 

20.0000 

16.0000 

4 

19.0000 

17.0000 

5 

16.0000 

18.0000 

6 

17.0000 

19.0000 

7 

16.0000 

20.0000 

Figure  9:  Objective  Values  Summary  Display 

Using  the  same  example,  Figure  10  contains  a  sample  of 
detailed  solution  display  available  through  the  PCADA 


system 


In  this  case,  the  4th  solution  is  shown 


NON-DOMINATED  SOLUTIONS  FOR  PROBLEM:  EXAMPLE 
***  SOLUTION  4  m 

-  OBJECTIVES  - 

1.  BOMBER  =  19.0000 

2.  FIGHTER  =  17.0000 

-  VARIABLES  - 

Decision  variable  xl  =  7.0000 

Decision  variable  x2  =  5.0000 

-  CONSTRAINT  SLACKS/SURPLUSES  - 

Constraint  I  1  (  X1SUPPLY  )  had  a  SLACK  =  3.0000 

Constraint  I  2  (  Y2SUPPLY  )  had  a  SLACK  =  3.0000 


Figure  10:  Detailed  Solution  Display 


All  PCADA  outputs  are  available  on  the  video  display  screen 
or  the  on  the  printer  in  hardcopy  -form. 


51 


1 


1 


1 

i 


VI  Concl usi ons  and  Recommendat i ons 

The  PCADA  package  fulfills  the  thesis  objective  of 
developing  a  mul ti ob j ect i ve  decision  analysis  package  for  a 
personal  computer.  Its  user  friendly  design  makes  the  pack¬ 
age  useful  for  personnel  of  varied  backgrounds  in  a  problem 
solving  environment.  Although  PCADA  has  undergone  fairly 
extensive  testing  by  the  author  and  others,  and  seems  to 
satisfy  all  of  the  research  objectives,  its  true  measure  of 
success  will  be  user  acceptance  over  a  period  of  time. 

Nonetheless,  all  objectives  and  subobjectives  as  stated 
in  chapter  I  have  been  implemented.  The  author  is  encour¬ 
aged  by  this  demonstration  that  today's  personal  computers 
can  indeed  be  effectively  utilized  for  implementation  of 
valuable  operations  research  techniques. 

PCADA  though  represents  only  the  "tip  of  the  multi  ob¬ 
jective  iceberg".  Other  techniques  including  goal  program¬ 
ming  and  the  iterative  weighting  method  (8:210)  would  be 
useful.  In  addition,  helping  decision  makers  establish 
their  objective  preferences  would  be  a  powerful  addition  to 
the  package. 

The  constraint  and  weighting  techniques  as  implemented 
could  also  be  enhanced  by  adding  sensitivity  analysis. 
Finally,  the  area  of  result  presentation  should  be 
investigated.  The  use  of  color  and/or  graphics  for  program 
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outputs  would  greatly  increase  the  program’s  effectiveness 
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I  Introduction 


The  Personal  Computer  Aided  Decision  Analysis  (PCADA) 
software  package  is  designed  to  meet  the  needs  of  managers 
and  analysts  through  easy-to-use,  time  responsive  computer 
support.  The  package  currently  implements  the  weighting  and 
constraint  multiobjective  decision  analysis  techniques.  It 
is  specifically  designed  to  exploit  the  capabilities  and 
responsiveness  of  commonly  available  desk— top  computers. 

The  purpose  of  this  document  is  to  explain  how  to  use 
PCADA.  That  is,  how  can  PCADA  be  used  by  managers  and  ana¬ 
lysts  of  all  disciplines  in  solving  mul t i ob j ecti ve  decision 
analysis  problems. 

Before  proceeding,  potential  system  users  should  do  two 
things.  First,  the  problem  needs  to  be  identified  as  a  type 
suitable  for  solution  by  this  package.  Specifically,  PCADA 
will  solve  multiple  objective  linear  programming  problems. 

There  are  three  characteristics  that  can  be  used  to 
identify  a  multiobjective  linear  programming  (MOLP)  problem. 
First,  the  problem  will  have  more  than  one  objective. 
(Actually  PCADA  can  also  be  used  to  solve  single  objective 
problems.)  The  second  characteri Stic  of  MOLP  problems  is  a 
set  of  one  or  more  constraints  associated  with  the  objec¬ 
tives.  Finally,  all  objectives  and  constraints  must  be 
linear  functions.  Before  using  PCADA  to  obtain  the  optimal 
problem  solution (s)  users  should  have  their  problem  formu¬ 
lated  and  ready  for  input. 
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The  second  thing  users  should  do  before  proceeding  is 
to  insure  the  availability  of  an  appropriate  personal  com¬ 
puter.  As  implemented,  PCADA  requires  a  Z80  based  microcom¬ 
puter  with  64K  of  random  access  memory,  two  disk  drives,  a 
printer,  and  a  video  display  screen. 

The  remainder  of  this  document  describes  how  to  use  the 
PCADA  software  to  solve  MOLP  problems.  Section  II  gives 
program  capabilities  and  limitations.  Section  III  presents 
general  program  input/syntax  rules.  How  the  system  is 
initiated  is  described  in  section  IV.  The  detailed  usage 
description  is  provided  in  section  V. 
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II  PCADA  Capabi 1 1 ti es  and  Li  mi  tat i ons 

The  PCADA  package  is  designed  to  solve  mul t i ob j ect i ve 
linear  programming  problems.  It  o-f-fers  both  the  weighting 
and  constraint  techniques. 

The  weighting  technique  uses  a  linear  combination  o-f 
the  objective  -functions  to  -form  a  new  objective  -function  and 
then  iteratively  solves  the  new  linear  programming  problem. 
There  are  a  number  o-f  passible  solutions  because  there  are 
several  linear  combinations  used  as  the  new  abjective  func¬ 
tion.  These  solutions  are  candidates  for  the  non— domi nated 
solution  set  (NDSS) .  The  constraint  technique  uses  one 
objective  function  as  the  objective  function  of  the  new 
problem.  The  rest  of  the  abjective  functions  are  adjoined 
as  equality  constraints  with  the  right  hand  side  equal  to 
one  of  a  range  of  values  appropriate  for  the  objective  func¬ 
tions.  Again  the  solutions  to  these  problems  are  candidates 
for  the  NDSS.  One  character i sti c  of  the  weighted  technique 
is  that  the  only  solutions  found  will  be  corner  point 
solutions  (intersections  of  constraints).  The  constraint 
technique  on  the  other  hand  finds  solutions  all  along  the 
frontier  defined  by  the  constraints  of  the  original  problem. 

When  the  user  defines  a  MOLP  problem  for  analysis, 
PCADA  saves  it  to  disk  for  future  use.  Thus  it  is  not 
necessary  to  re— specify  problem  descriptions  prior  to  each 
solution  iteration.  Furthermore,  this  facilitates  sensitiv¬ 


ity  studies  where  users  can  examine  the  effect  on  answers  of 


subtle  problem  modifications.  For  this  purpose,  PCADA 
offers  a  broad  range  of  modification  options  that  also  allow 
quick  and  easy  re-solution  as  problem  conditions  change. 

Following  problem  solution,  PCADA  offers  extensive 
solution  display  options.  At  the  users  request,  solution 
outputs  can  range  from  simple  objective  value  summaries  to 
detailed  solution  displays  that  contain  objective  values, 
objective  weights  (if  requested,  for  the  weighting  technique 
only),  decision  variable  values,  and  constraint  slack  or 
surplus  values. 

In  general ,  PCADA  is  responsive  with  solutions  requir¬ 
ing  less  than  four  seconds  per  iteration.  However,  as  the 
number  of  objectives  increases  and  the  size  of  the  iteration 
increment  (as  specified  by  the  user)  decreases,  the  number 
of  iterations  can  quickly  become  large.  Thus  when  estab¬ 
lishing  the  solution  parameters,  users  need  to  be  aware  that 
the  time  required  to  compute  the  set  of  non— dominated 
solutions  is  directly  related.  Some  problems  can  require  on 
the  order  of  thirty  or  more  minutes  of  uni nterrupted 
computer  time.  For  example,  using  the  constraint  technique, 
a  problem  with  four  objectives  using  ten  steps  to  cover  the 
range  of  each  objective  would  require  approximately  66 
minutes  to  compute  the  non-domi nated  solution  set.  Still, 
this  time  compares  vary  favorably  with  the  time  that  would 
be  required  using  the  normally  less  accessible  "large-scale" 
computers  (if  available). 


Because  of  the  limited  memory,  disk,  and  speed  capabil¬ 
ities  of  personal  computers,  the  PCADA  software  can  only 
process  problems  that  are  within  the  following  limitations: 

—  no  more  than  4  objectives 

—  no  more  than  10  constraints 

—  no  more  than  10  decision  variables. 

Problems  that  are  more  complex  should  be  solved  using  large- 
scale  computer  based  decision  analysis  packages. 


Ill  Input  Rules 


Users  should  respond  to  each  PCADA  prompt  by  entering 
the  requested  data  on  the  computer  keyboard.  The  return  key 
must  be  pressed  after  the  data  value.  Users  need  not  be 
concerned  with  whether  their  inputs  are  upper  case  or  lower 
case,  as  all  lower  case  characters  are  internally  converted 
to  upper  case. 

All  inputs  are  subjected  to  range  and  error  checks  by 
the  software  as  they  are  made.  When  a  problem  is  detected, 
the  user  is  immediately  in-formed  with  a  descriptive  error 
message.  Error  messages  are  generally  sel f-expl anatory  and 
identify  what  is  wrong  with  the  input.  Following  the  error 
message  the  prompt  which  was  answered  in  error  is  again 
issued,  giving  the  user  the  chance  to  respond  correctly,  and 
then  continue  normal  program  processing. 

To  simplify  the  input  burden,  a  number  of  input  rules 
apply  throughout  the  PCADA  system. 

Obtaining  a  Pi  sol av/Pr i ntout  of  the  Currently  Active 
Problem.  During  processing,  users  may  need  to  refer  to  the 
problem  being  processed.  To  obtain  a  display  of  the  problem 
on  the  video  display  screen  users  can  enter  in  response 
to  any  program  menu  or  question.  Figure  11  contains  a 
sample  of  the  problem  display  as  generated  by  PCADA. 
Following  problem  display,  program  control  reverts  to  the 
point  where  the  request  was  made.  Users  desiring  a  perma¬ 
nent  hardcopy  display  of  their  problem  can  enter  "»1P" 


PROBLEM  NAME  =  EXAMPLE 


-  OBJECTIVES  - 

1.  MAXIMIZE  BOMBER  =  +2.00x1  +1.00x2 

2.  MAXIMIZE  FI6HTER  =  +1.00x1  +2.00x2 


■SUBJECT  TO  THE  FOLLOWING  CONSTRAINTS 


1.  xisupply: 

+1.00x1 

+0.00x2 

<= 

10.00 

2.  X2SUPPLY: 

+0.00x1 

+1.00x2 

<= 

8.00 

3.  AC-LIMIT: 

+1.00x1 

+1.00x2 

<= 

12.00 

Figure  11:  Sample  Problem  Display 

instead  o-f  “e" .  Again  after  the  printing  process  is 
completed  program  control  reverts  to  the  point  at  which  the 
request  was  made.  NOTE:  This  option  works  only  after  a 
legitimate  problem  has  been  defined  or  loaded  from  disk. 

Obtaining  HELP  concerning  any  PCADA  menu  or  Question. 
Although  most  PCADA  prompts  are  self-explanatory,  users  that 
need  assistance  understanding  any  system  menu  or  question 
can  obtain  clarifying  information  by  entering  "HELP"  or  "?" 
in  response  to  the  question.  The  system  will  respond  to  the 
request  by  presenting  information  directly  related  to  the 
prompt  on  the  video  display  screen.  Following  presentation 
of  the  HELP  information,  the  original  question  or  menu  is 
redisplayed  and  processing  continues  in  the  normal  fashion. 

Responding  to  a  Menu.  The  PCADA  system  makes  exten¬ 


sive  use  of  menus  to  determine  a  user’s  choice  of  processing 


options.  When  presented  with  a  menu,  users  should  examine 
the  options  and  enter  the  integer  value  corresponding  to  the 
desired  option. 

Floating  point,  text,  integer  values  that  exceed  the 
menu’s  range,  or  other  non-integer  inputs  will  result  in  an 
appropriate  error  message.  On  most  menus,  an  input  of  0 
(zero)  will  cause  program  control  to  revert  to  the  previous 
menu.  In  this  way,  users  can  recover  from  erroneous  menu 
selections.  Finally,  if  the  return  key  is  entered  with  no 
input,  PCADA  assumes  that  the  user  wants  the  value  0  (zero). 
This  feature  can  be  used  to  save  keystrokes  when  zero  is  de¬ 
sired  or  when  the  user  wants  to  quickly  revert  to  a  previous 
menu. 

Responding  to  a  Question— Floating  Point.  PCADA  asks 
several  questions  requiring  a  floating  point  value  input. 
Users  should  respond  by  entering  the  value  in  decimal  for — 
mat.  For  example,  the  value  523  should  be  entered  as  "523. “ 
or  "523.0"  or  simply  "523".  The  system  will  reject  other 
representations  such  as  5.23E+2.  For  these  representations, 
text  inputs,  out  of  range  values,  or  other  illegal  values 
the  system  will  generate  an  error  message  as  appropriate. 
Note  that  integer  values  are  acceptable  and  are  converted  to 
floating  point  internally.  In  addition,  as  with  menus,  if 
the  return  key  is  entered  with  no  input,  a  value  of  0.0  is 
assumed.  This  feature  can  be  used  to  quickly  enter  coeffi¬ 
cients  and  constraint  right  hand  sides  whose  value  is  zero. 
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Responding  to  a  Question-Integer.  PCADA  asks  several 


questions  that  require  an  integer  valued  response.  (Menus 
are  a  special  case  of  integer  valued  questions.)  All  inputs 
other  than  integers  (including  -floating  point  values)  will 
result  in  an  appropriate  error  message.  As  before,  if  no 
input  is  entered,  it  is  assumed  to  be  the  value  0  (zero). 

Responding  to  a  Question-Yes  or  No.  The  PCADA  pack¬ 
age  asks  several  questions  that  require  a  YES  or  NO  response 
from  the  user.  All  of  these  questions  have  been  converted 
to  menus.  As  indicated,  users  should  enter  "l"  when  wanting 
to  answer  "yes'1,  and  "2"  when  a  "no"  response  is  appropri¬ 
ate.  All  other  responses  will  result  in  an  explanatory 
error  message. 

Responding  to  a  Question-Text.  The  PCADA  package  asks 
several  questions  that  require  a  text  valued  response.  The 
rules  concerning  text  input  vary  depending  on  how  the  item 
is  to  be  used.  For  example,  the  program  will  prompt  the 
user  for  a  name  to  be  used  to  identify  the  problem.  This 
item  is  required  and  is  subsequently  used  as  a  disk  file 
name  for  saving  the  problem.  Because  of  its  usage,  the 
first  character  must  be  a  letter  (rather  than  a  number  or 
special  character).  In  all  cases,  text  rules  are  identified 
in  the  question  and  if  needed,  explanatory  error  messages 
are  presented.  For  optional  text  inputs,  entering  the 
return  key  with  no  input  will  result  in  the  default  value  of 
all  blanks. 
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Prior  to  initiating  the  PCADA  software  package,  users 
should  have  an  initialize  diskette  that  is  not  write 


9 


protected  that  can  be  used  for  storing  the  problems  that  are 
going  to  be  worked.  It  is  not  necessary  to  use  a  different 
diskette  each  time,  as  each  problem  file  requires  less  than 
2K  bytes  of  disk  storage  and  many  problems  can  be  stored  on 
each  diskette. 

If  the  user  plans  to  access  problem  files  that  were 
created  at  a  previous  PCADA  session,  he  should  insure  that 
he  has  the  correct  problem  file  names.  All  problem  files 
are  stored  on  the  problem  diskette  using  the  name  supplied 
by  the  user  when  the  problem  was  first  defined.  Problem 
disk  files  can  be  identified  as  those  of  type  "PRB". 

When  ready  to  begin  after  turning  the  power  on  to  the 
computer  system,  the  user  should  insert  the  write  protected 
PCADA  system  diskette  into  disk  drive  #1  ,  and  the  problem 
file  diskette  (not  write  protected)  into  disk  drive  #2.  At 
this  point  the  PCADA  software  is  started  by  entering  the 
command:  "PCADA."  Detailed  usage  of  the  software  from  this 


point  is  described  in  the  next  section. 


*  PERSONAL  COMPUTER  AIDED  DECISION  ANALYSIS  * 

f  * 

♦  (PCADA)  * 

t  t 

This  prograa  is  designed  to  siaplify  the  decision  taking  process.  It  does  so 
by  providing  an  easy  to  use  tool  for  solving  aultiple  objective  problets. 


- —  6ENERAL  INSTRUCTIONS  - 

Although  tost  prograa  proapts  are  self-explanatory,  you  aay  receive  clarifying 
infcraation  to  any  question  by  responding  to  it  with  'HELP*  or  *?'.  Once  you 
have  defined  a  problea  or  loaded  one  froa  disk,  you  aay  have  it  displayed  on  the 
screen  (or  at  the  printer)  by  entering  'V  (for  printer  enter  *@P*)  in  response 
to  any  question  or  aenu.  Before  continuing,  please  insure  that  you  have  an 
initialized  diskette  for  problea  files  installed  in  disk  drive  2. 

WHEN  READY  TO  BEGIN,  PRESS  THE  CARRIAGE  RETURN  BUTTON  (CR) 


When  the  user  is  ready  to  proceed,  he  strikes  the  carriage 
return  button  <hereaf ter  ref erred  to  as  CR> . 

At  this  point,  the  screen  will  clear,  and  the  user  will 
be  asked  which  means  he  wishes  to  use  to  obtain  a  problem 
definition.  The  following  menu  is  used  for  this  purpose: 


Before  you  can  solve  a  problea  you  oust  define  a  net*  one  or  retrieve  a  previous¬ 
ly  defined  one  froa  disk.  Please  indicate  the  Beans  you  tush  to  use  to  obtain 
an  active  problea  definition:  (NOTE:  To  exit  the  prograa  non,  enter  *0") 

1.  Load  a  previously  defined  problea  froa  disk 

2.  Define  a  new  problea 

The  above  menu  is  referred  to  as  "system  level  menu  #1". 
The  description  of  each  of  the  menu  options  is  given  in  the 
next  section. 

Whenever  the  user  completes  a  problem  iteration,  that 


is,  when  he  completes  his  examination  of  his  problem 
solution  results,  he  is  again  faced  with  a  "system  level" 
menu  as  follows: 

Please  select  your  next  operation  fro*  the  following  senu: 

(NOTE:  To  exit  the  prograi  now,  enter  ‘O’) 

1.  Retrieve  a  different  proble*  fro*  disk 

2.  Define  a  new  problet 

3.  Edit  the  currently  active  proble* 

4.  Solve  the  currently  active  proble* 

This  menu  is  referred  to  as  "system  level  menu  #2".  Options 

1  and  2  cause  the  same  processing  sequence  as  options  1  and 

2  of  the  previous  menu.  These  options  are  described  in  the 
problem  definition  section.  Option  3  allows  the  user  to 
modify  the  currently  active  problem.  It  is  also  described 
in  the  problem  definition  section.  The  processing  related 
to  option  4  is  decribed  in  the  problem  solving  section. 

If  the  user  enters  "0“  to  either  of  the  system  level 
menus,  processing  terminates  and  the  following  closing 
message  is  displayed: 

PERSONAL  COMPUTER  AIDED  DECISION  ANALYSIS 
IPCADA) 

Proble»s  that  you  defined  this  session  have  been  saved  to  disk.  Your  proble* 
files  can  be  identified  on  the  proble*  diskette  as  those  of  type  *PRB‘.  You 
should  take  care  to  aanage  those  files  by  deleting  or  re-defining  those  that  are 
obsolete.  Also,  please  sake  note  of  your  proble*  file  nates  for  future  use. 


—  END  PROGRAM  — 


Problem  Definition  Function 

There  are  two  methods  available  to  users  to  obtain  a 
problem  definition  for  the  PCADA  system  to  solve.  The 
first,  as  requested  by  selecting  option  1  from  either  of  the 
system  level  menus  described  above,  loads  a  previously 
defined  problem  from  disk.  NOTE:  Problems  that  are  loaded 
in  this  fashion  must  have  previously  been  defined  directly 
by  the  PCADA  system. 

The  second  method  for  obtaining  a  problem  definition  is 
requested  by  selecting  option  2  from  either  of  the  system 
level  menus  previously  described.  This  method  is  used  for 
new  problems  that  are  not  already  saved  on  disk.  With  this 
method  users  are  prompted  to  enter  all  the  information 
needed  to  complete  a  problem  description. 

Obtaining  a  Problem  from  Disk.  This  function  will  ac¬ 
cess  the  problem  diskette  that  is  installed  in  disk  drive  #2 
to  obtain  the  desired  problem  file.  First  though,  the  user 
must  specify  the  name  of  the  desired  problem  file.  He  is 
given  the  opportunity  to  do  so  by  responding  to  the 
following  question: 

Please  enter  the  naae  of  the  probles  that  you  no*  nant  to  load  fro*  disk: 

NOTE:  By  definition,  disk  file  names  must  be  from  2  to  8 
upper  case  alphanumeric  characters  with  the  first  character 
being  a  letter.  Special  characters  are  not  allowed. 


The  PCADA  system  appends  the  file  type  of  "PRB"  to  each 


problem  -file  name  but  users  need  not  enter  the  “PRB" . 

If  the  requested  problem  file  is  available  on  the  prob¬ 
lem  disk  and  no  read  or  other  input/output  error  occurs,  the 
problem  is  loaded  into  the  program  work  areas  and  program 
control  reverts  to  system  level  menu  2.  That  is,  a  problem 
has  now  been  defined  and  the  user  is  free  to  select  the  next 
program  option. 

If  the  requested  problem  file  does  not  exist  or  some 
other  input /output  error  occurs,  the  user  is  presented  the 
following  menu: 

A  disk  input/output  error  has  occurred.  Please  sake  sure  that  the  problea 
diskette  is  installed  in  drive  12,  the  disk  drive  door  is  dosed,  and  that  you 
have  entered  the  correct  file  naae. 

Would  you  like  to  try  again? 

1.  Yes 

2.  No 

As  indicated,  the  program  is  unable  to  obtain  the  desired 
problem  file  for  what  could  be  one  of  many  reasons.  Even  if 
none  of  the  suggestions  apply,  it  is  a  good  idea  to  remove 
the  problem  diskette,  then  reinsert  and  "reseat"  it  and  try 
again. 

The  spelling  of  the  desired  file  name  must  match  exact¬ 
ly.  To  obtain  a  list  of  file  names  of  the  problem  diskette 
the  user  must  exit  the  PCADA  program  and  use  the  computer’s 
disk  operating  system  to  examine  the  disk  contents. 

If  all  else  fails,  it  is  possible  that  somehow  the 
problem  diskette  has  been  damaged.  If  this  is  the  case,  the 
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desired  problem  will  have  to  be  reentered  and  saved  to  a  new 
diskette.  For  problems  which  are  long  or  complex  it  is  a 
good  idea  tor  users  to  keep  backup  copies  ot  them.  Refer  to 
the  computer’s  manuals  for  instructions  on  how  to  make  back¬ 
up  disk  copies. 

Defining  a  New  Problem  File.  The  PCADA  system  can  be 
used  to  input  new  problems  for  analysis.  This  option  is 
invoked  by  selecting  option  ,,2‘‘  from  either  of  the  system 
level  menus  previously  discussed.  When  users  first  enter 
this  function,  the  video  display  screen  will  be  cleared  and 
the  following  introductory  message  will  appear: 

DEFINE  NEK  HULTIQ8JECTIVE  PROBLEM 

In  this  nodule,  you  will  be  defining  a  new  «ulti objective  probles  to  be  solved. 

You  should  now  be  prepared  to  enter  the  objective  functions  (up  to  four),  and 
the  constraints  (up  to  10).  NOTE:  If  you  sake  a  sistake  on  soee  entry,  you 
can  easily  correct  and/or  sodify  your  proble*  later  using  the  EDIT  sodule. 

Also,  your  probles  will  autoaatically  be  saved  to  disk  for  later  use. 

The  first  required  input  for  defining  a  new  problem  is  the 
problem  name.  For  this  the  user  is  prompted  as  follows: 

Please  enter  the  nase  you  wish  to  use  for  referring  to  this  probles: 

(NOTE:  If  you  wish  to  stop  now,  enter  ’STOP') 

Again,  filenames  must  be  from  2  to  8  alphanumeric  characters 
with  the  first  character  being  a  letter. 

The  system  will  prevent  the  inadvertent  loss  of  exist¬ 
ing  problem  files  by  checking  to  see  if  the  name  requested 
is  already  in  use  as  a  disk  problem  filename.  If  PCADA 
finds  a  conflict  it  asks  the  user  if  this  was  intended  as 


73 


■foil  ows: 


The  naae  you  selected  is  already  in  use  as  a  proble#  Tile  nase.  Co  you  Nish  to 
redefine  that  proble#  no n? 

1.  Yes 

2.  No 

I-f  the  user  selects  option  "1"  (yes),  then  the  existing  -file 
is  lost  and  will  be  rede-fined  with  a  new  problem  descrip¬ 
tion.  It  the  user  selects  option  ,,2"  (no),  then  the  exist¬ 

ing  -file  is  le-ft  intact  and  the  user  will  be  asked  -for  a  new 
problem  name  as  before  using  menu  10  (see  above). 

Next,  PCADA  will  ask  the  user  how  many  decision  vari¬ 
ables  the  problem  contains  with  the  -following  question: 

Hon  *any  variables  does  your  proble*  contain? 

NOTE:  The  number  of  decision  variables  in  a  problem  can 

easily  be  changed  later  using  the  problem  edit  capabilities. 
Thus,  if  the  user  makes  a  mistake  in  input  now,  it  can  be 
corrected  later. 

Problems  must  contain  at  least  one  decision  variable 
and  are  limited  to  a  maximum  of  10. 

At  this  point,  PCADA  will  enter  a  loop  to  obtain  the 
problem’s  objectives.  A  maximum  of  four  objectives  is 
allowed  and  at  least  one  is  required.  The  program  will 
continue  to  prompt  the  user  for  objective  function  data 
until  the  user  has  input  four  or  until  the  user  indicates 
that  there  are  no  more. 
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Entering  Objective  Functions.  The  first  input 
related  to  objectives  is  the  objective  name.  This  item  is 
not  required  for  problem  solutions  but  is  available  to  help 
clarify  problem  results.  Thus,  the  user  should  enter  the 
name  that  you  wish  to  associate  with  the  objective.  COST, 
PROFIT,  or  REVENUE  would  be  typical  of  objective  names. 
Abbreviations  are  encouraged  since  the  name  is  limited  to  8 
alphanumeric  characters.  Since  this  item  is  optional,  no 
input  (i.e.  CR  only)  will  be  accepted  and  processed  as  all 
blanks.  Objective  names  are  requested  with  the  following 
menu: 


Please  enter  the  nase  or  target  quantity  that  this  objective  represents.  If 
there  are  no  aore  objectives  for  this  problea,  enter  '/\ 

NOTE:  This  menu  is  used  to  signal  the  PCADA  system  that 

there  are  no  more  problem  objectives,  by  entering  "/". 

Next,  the  user  specifies  if  the  objective  is  to  be 
maximized  or  minimized  by  responding  to  the  following  menu: 

Please  specify  the  objective  function  type: 

1.  Maxi aize 

2.  Mi ni aize 

Now  the  user  will  be  asked  for  the  objective  function 
coefficients.  The  prompts  occur  one  at  a  time  and  there 
will  be  one  for  each  decision  variable  in  the  problem.  The 
menu  will  specify  the  identification  of  the  decision 
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variable  as  follows: 


Enter  objective  coefficient  for  variable  xl 


Recall  that  entering  CR  with  no  input  will  be  interpreted  as 
a  value  of  0.0.  This  -feature  can  be  used  to  speed  the 
objective  input  process.  In  addition,  erroneous  inputs  can 
be  corrected  later  using  the  PCADA  edit  functions.  After 
the  above  question  has  been  asked  for  each  decision  vari¬ 
able,  the  objective  function  has  been  completely  specified. 
Control  will  revert  back  to  the  start  of  this  section  to 
receive  function. 

When  the  user  indicates  that  there  are  no  more  objec¬ 
tives,  the  PCADA  system  will  enter  a  similar  loop  to  obtain 
the  problem  constraints.  A  maximum  of  10  constraints  are 
allowed  and  at  least  one  is  required.  Users  that  plan  to 
utilize  the  constraint  technique  are  subjected  to  a  differ — 
ent  constraint  limit.  Since  the  constraint  technique  adds 
all  but  one  of  the  objectives  to  the  problem  as  constraints, 
the  maximum  number  of  constraints  is  related  to  the  number 
of  objectives  as  follows: 

limit 

#  of  objectives  #  of  constraints 

1  10 

2  9 

3  8 

4  7 

(applies  to  constraint  technique  only) 

The  program  assumes  the  existence  of  the  non-negativity 
constraints.  Thus  they  need  not  be  entered  by  the  user. 


Entering  Constraints. 


The  first  input  related  to 


constraints  is  the  constraint  name.  This  optional  item  is 
offered  to  help  clarify  problem  results.  Users  should  enter 
the  name  that  they  wish  to  associate  with  the  constraint. 
MONEY,  LABOR,  or  MATERIAL  would  be  typical  of  constraint 
names.  Abbreviations  are  encouraged  since  the  constraint 
name  is  limited  to  8  alphanumeric  characters.  Since  this 
item  is  optional,  no  input  will  be  processed  as  all  blanks. 
Constraint  names  are  requested  with  the  following  menu: 

Please  enter  the  name  of  the  resource  that  this  constraint  represents.  If 
there  are  no  iore  constraints  for  the  problei,  enter  */*. 

NOTE:  This  menu  is  used  to  signal  the  PCABA  system  that 

there  are  no  more  problem  constraints  by  entering  . 

Next,  the  user  is  prompted  for  the  constraint  coeffi¬ 
cients.  The  values  are  requested  one  at  a  time,  one  for 
each  decision  variable  in  the  problem.  The  question  will 
specify  the  identification  of  the  variable  as  follows: 

Enter  constraint  coefficient  for  variable  xl 

As  before,  blank  (CR  only)  inputs  will  be  interpreted  as  a 
value  of  0.0  and,  erroneous  inputs  can  easily  be  corrected 
later  using  PCADA  edi*  functions. 

Next,  the  type  of  relation  that  is  to  be  used  for  the 
constraint  is  requested.  That  is,  is  the  resource  that  the 
constraint  represents  lower  bounded,  upper  bounded,  or  to  be 
exactly  specified?  The  relation  type  is  requested  via  the 
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-following  menu: 


Please  specify  the  type  of  relation  applicable  to  this  constraint: 

1.  less  than  or  equal 

2.  equal 

3.  greater  than  or  equal 

Finally,  the  limiting  value  that  pertains  to  the  con¬ 
straint  must  be  speci-fied  by  the  user.  PCADA  software  uses 
the  -following  question  to  request  this: 

Please  specify  the  right  hand  side  value  for  this  constraint: 

As  with  objective/constraint  coe-f -f icients,  a  blank  input 
will  be  interpreted  as  the  value  0.0.  Also,  i-f  an  error  is 
made,  constraint  right  hand  side  can  be  corrected  later 
using  PCADA  edit  capabi 1 i ti es. 

Editing  a  Problem.  The  PCADA  system  o-f-fers  users  the 
opportunity  to  alter  problem  parameters  without  having  to 
completely  respecify  the  entire  problem.  This  option  can  be 
used  when  users  detect  an  error  in  problem  specification,  or 
if  the  problem  conditions  have  changed.  The  editing  func¬ 
tion  is  invoked  by  selecting  option  "3"  from  system  level 
menu  #2.  NOTE:  System  level  menu  #2  i s  generated  automat¬ 
ically  after  each  major  processing  request.  For  example, 
after  defining  a  problem,  control  reverts  to  system  level 
menu  #2.  This  section  describes  the  nine  problem  editing 
functions  provided  by  the  PCADA  system. 


When  the  user  first  indicates  his  desire  to  enter  the 


problem  modi -f i cati on  function,  the  screen  is  cleared  and  the 
following  introductory  remarks  and  menu  are  presented: 


EDIT  PROBLEM 


This  function  allows  you  to  EDIT  the  proble*  that  is  currently  loaded  into 
prcqraa  aeaory.  Whenever  an  objective,  constraint,  or  variable  is  to  be  ref¬ 
erenced  by  nuaber,  the  nuabers  are  as  they  appear  on  the  problea  printout  that 
can  be  obtained  by  entering  '8P'  (or  ’§'  for  screen)  in  response  to  any  aenu. 

Please  select  froa  the  following  EDIT  functions: 

(NOTE:  Enter  ’0"  to  exit  the  EDIT  function! 


1.  Add  objective  function 

2.  Delete  objective  function 

3.  Add  constraint 

4.  Delete  constraint 

5.  Add  variable 


h.  Delete  variable 

7.  EDIT  objective  coefficients 

8.  EDIT  constraint  coefficients 

9.  EDIT  constraint  right  hand  side 


This  menu  is  referred  to  as  the  main  editing  menu,  from  it 
the  user  indicates  the  editing  option  that  is  needed.  Fol¬ 
lowing  completion  of  each  editing  task,  the  above  display  is 
again  presented  giving  the  user  the  opportunity  to  perform 
additional  editing  functions.  As  indicated,  when  the  user 
has  completed  all  editing  operations  he  should  enter  "O'*  (or 
just  the  CR) ,  to  cause  program  control  to  revert  to  system 
level  menu  #2,  from  which  the  problem  can  be  solved. 

Add  Objective  Function.  Before  allowing  the  user 
to  add  an  objective  function  PCADA  will  check  to  make  sure 
that  the  problem  currently  has  less  than  the  program  limit 
of  four  objectives.  If  the  problem  has  4  objectives,  the 
following  message  is  displayed: 


««  YOUR  PROBLEM  ALREADY  HAS  THE  MAXIMUM  OF  4  OBJECTIVE  FUNCTIONS  «*♦ 
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The  program  then  reverts  to  the  main  editing  menu  that  was 
presented  at  the  start  of  this  section  to  process  the  next 
editing  request. 

If  the  problem  has  less  than  4  objectives,  the  program 
will  prompt  the  user  for  all  the  necessary  objective 
information.  The  process  is  as  described  above  under  the 
"Entering  Objective  Function"  section.  As  with  all  editing 
functions,  following  completion  of  the  action,  the  main 
editing  menu  is  presented  for  additional  editing  requests. 

Delete  Objective  Function.  Before  allowing  the 
user  to  delete  an  objective  function,  PCADA  checks  to  make 
sure  that  the  current  problem  has  at  least  two  objectives. 
Each  problem  must  have  at  least  one  abjective  and  PCADA  will 
not  allow  deletion  of  the  last  objective.  If  the  user 
selects  this  option  and  the  problem  has  only  one  objective, 
the  following  messages  is  displayed: 

*♦**  YOUR  PROBLEM  CURRENTLY  HAS  THE  MINIMUM  ALLOWABLE  l  OBJECTIVE  #♦*» 

If  the  problem  has  more  than  one  objective  then  objec¬ 
tive  deletion  is  allowed  and  the  user  will  select  the  objec¬ 
tive  to  be  deleted  from  the  following  menu: 

DELETE  OBJECTIVE 

1.  objective  1 

2.  objective  ! 

3.  objective  J 

4.  objective  4 


Please  specify  which  of  the  above  objectives  you  now  wish  to  delete*. 
(NOTE;  Enter  ’0"  if  you  have  changed  your  nind) 


When  executed  the  above  menu  will  contain  from  two  to  four 
objectives  depending  on  how  many  objectives  the  problem 
contains.  In  addition,  rather  than  "objective  n"  the  menu 
will  contain  the  name  that  was  assigned  to  the  objective 
when  the  problem  was  defined. 

The  user  should  select  the  objective  that  is  to  be 
deleted.  If  the  user  decides  that  he  now  does  not  want  to 
delete  an  objective,  he  should  enter  “0“  to  keep  the  problem 
unchanged. 

Add  Constraint.  Before  allowing  the  user  to  add 
a  constraint  to  the  problem,  PCADA  will  check  to  make  sure 
that  the  problem  currently  has  less  than  the  program  limit 
of  ten  constraints.  If  the  problem  already  has  ten  con¬ 
straints,  the  following  message  is  displayed: 

«**  YOUR  PROBLEM  ALREADY  HAS  THE  HAXIHUH  OF  10  CONSTRAINTS  t**» 

The  program  then  reverts  to  the  main  editing  menu  to  process 
the  next  editing  request. 

If  the  problem  has  less  then  10  constraints  the  program 
will  prompt  the  user  for  all  the  necessary  constraint  inf or — 
mation.  The  process  is  as  described  under  the  "entering 
constraint"  section.  As  with  all  editing  functions, 
following  completion  of  the  action,  the  main  editing  menu 
is  presented  for  additional  editing  requests. 

Delete  Constraint.  Before  allowing  the  user  to 
delete  a  constraint.  PCADA  checks  to  make  sure  that  the 


current  problem  has  at  least  two  constraints.  Each  problem 
must  have  at  least  one  constraint  and  PCADA  will  not  allow 
deletion  o-f  the  last  constraint.  If  the  user  selects  this 
option  and  the  problem  has  only  one  constraint,  the  follow¬ 
ing  message  is  displayed: 

«**  YOUR  PROBLEM  CURRENTLY  HAS  THE  MINIMUM  ALLOWABLE  1  CONSTRAINT  **** 

If  the  problem  has  more  than  one  constraint,  then 
constraint  deletion  is  allowed  and  the  user  will  make  his 
choice  from  the  following  menu: 

DELETE  CONSTRAINT 

1.  constraint  1 

2.  constraint  2 

3.  constraint  3 

■ 

(up  to  10  constraints) 

Please  specify  which  of  the  above  constraints  you  now  wish  to  delete: 

(NOTE:  Enter  'O'  if  you  have  changed  your  Bind) 

When  this  option  is  executed,  the  above  menu  will  contain 
from  two  to  ten  constraints  depending  on  the  current  prob¬ 
lem.  In  addition,  rather  than  "constraint  n ",  the  menu 
will  contain  the  name  that  was  assigned  to  the  constraint 
when  the  problem  was  defined. 

The  user  should  select  the  constraint  that  is  to  be 
deleted.  If  the  user  decides  that  he  now  does  not  want  to 
delete  an  constraint,  he  should  enter  "0"  to  prevent  the 
problem  from  being  altered. 


Add  Variable.  This  function  is  used  to  add 
decision  variables  to  the  current  problem.  Before  adding  a 
variable,  PCADA  checks  the  current  problem  to  insure  that  it 
is  not  already  at  the  variable  limit  of  ten.  If  it  is,  then 
the  following  message  is  displayed: 

n»  YOUR  PRQBLEH  ALREADY  HAS  THE  HASUHIUN  OF  10  VARIABLES 

If  the  problem  contains  less  than  10  variables  then  a 
variable  is  added.  The  new  variable  is  assigned  the  next 
sequential  variable  number.  That  is,  if  the  problem  cur — 
rently  contains  six  variables  the  new  variable  will  be  X7. 
All  constraint  apd  objective  coefficients  corresponding  to 
the  new  variable  are  initialized  to  a  value  of  0.0.  The 
appropriate  EDIT  functions  should  be  used  to  set  these 
coefficient  values  where  appropriate  (see  below).  When  the 
variable  is  added,  the  following  message  is  displayed: 

VARIABLE  ADDED  =  xN 

A  variable  has  been  added  to  your  problei.  The  coefficient  values  for  this 
variable  for  all  objectives  and  constraints  has  been  initialized  to  a  value  of 
0.0.  If  you  need  to  alter  these  values,  you  »ay  do  so  using  the  EDIT  functions 
to  EDIT  objectives  and  constraints  accordingly. 

PRESS  THE  RETURN  KEY  WHEN  READY  TO  CONTINUE... 

NOTE:  N  will  be  set  to  the  added  variable  number,  a  value 
from  2  to  10. 

Delete  Variable.  This  function  is  used  to 
delete  decision  variables  f;-om  the  current  problem.  Before 
deleting  a  variable,  PCADA  checks  the  current  problem  to 


insure  that  it  is  not  already  at  the  variable  minimum  o-f  1. 


If  it  is,  then  the  following  message  is  displayed: 

*»*  YOUR  PROBLEM  ALREADY  HAS  THE  MINIMUM  OF  I  VARIABLE  »*♦ 

If  the  problem  currently  contains  more  than  one  vari¬ 
able  then  a  variable  may  be  deleted.  To  determine  which  one 
to  delete,  PCADA  presents  the  following  menu: 

Please  input  the  nueber  of  the  variable  you  wish  to  delete: 

(NOTE:  Enter  '0'  if  you  have  changed  your  »ind) 

As  indicated  above,  if  the  user  no  longer  wishes  to  delete  a 
variable  he  can  avoid  doing  so  by  entering  "O''.  Otherwise, 
the  user  should  specify  which  variable  to  delete. 

It  is  important  to  note  that  when  a  variable  is 
deleted,  the  remaining  variables  are  uppacked.  That  is,  if 
the  current  problem  contains  six  variables  and  the  user 
deletes  variable  X4,  then  X5  will  be  redefined  as  X4  and  X6 
will  be  redefined  as  X5. 

Edit  Objective  Function  Coefficients.  This  func¬ 
tion  is  used  to  alter  the  objective  coefficients.  When 
selected,  a  menu  is  presented  as  follows: 

EDIT  OBJECTIVE  FUNCTION 

1.  objective  1 

2.  objective  2 

3.  objective  J 

4.  objective  4 

Please  specify  the  nuiber  of  the  objective  function  ithose  coefficients  you 

Mould  like  to  EDIT:  (NOTE:  Enter  'O'  if  you  are  done  editing) 


The  above  menu  will  contain  only  the  number  of  entries  as 
there  are  objectives  in  the  current  problem.  In  addition, 
in  the  operational  menu  ’  objective  r>’  is  replaced  by  the 
objective  name  as  specified  when  the  problem  was  defined. 

The  user  should  select  the  objective  that  he  wishes  to 
EDIT.  When  no  more  objective  functions  are  to  be  edited, 
the  user  should  enter  'O’.  Control  will  be  returned  to  the 
main  problem  editing  menu.  Once  the  objective  has  been 
selected,  the  specific  coefficient  that  is  to  be  modified 
needs  to  be  identified.  For  this,  the  following  menu  is 
presented : 

EDIT  OBJECTIVE  FUNCTION 

Following  are  the  objective  coefficients  for  objective  to;  naif 

1.  Coefficient  for  variable  xl  =  value 

2.  Coefficient  for  variable  x2  =  value 

3.  Coefficient  for  variable  *3  =  value 

■ 

(repeated  for  each  decision  variable) 

Please  specify  the  nueber  of  the  coefficient  that  you  would  like  to  change: 

(NOTE:  When  done  editing,  enter  'O’) 

"Objective  #t>“  will  indicate  the  number  of  the  selected 
objective,  "naee11  will  indicate  that  objective’s  name.  In 
addition,  the  menu  will  contain  one  entry  for  each  decision 
variable,  to  a  maximum  of  10.  The  user  should  select  that 
coefficient  he  wishes  to  edit.  When  no  more  coefficients  of 
this  objective  are  to  be  changed,  the  user  should  enter  “O'*. 
He  will  then  be  returned  to  the  menu  which  gives  him  the 


option  of  editing  other  objectives. 

If  the  user  decides  to  edit  one  of  the  coefficients  the 
following  menu  is  presented: 

Please  specify  the  new  coefficient  value: 

The  user  should  enter  the  new  objective  coefficient  as  a 
floating  point  value.  After  entering  the  value,  control 
reverts  to  menu  28  to  allow  the  user  to  edit  the  other 
coefficients  in  the  objective. 

Edit  Constraint  Coefficients.  This  function  is 
used  to  alter  the  constraint  coefficients.  When  selected,  a 
menu  is  presented  as  follows  (menu  30): 

EDIT  CONSTRAINT 

1.  constraint  l 

2.  constraint  2 

3.  constraint  J 

(up  to  10  constraints) 

Please  specify  the  number  of  the  constraint  whose  coefficients  you  Nould  like  to 

EDIT:  (NOTE:  If  you  are  done  editing  coefficients,  enter  *0") 

The  above  menu  will  contain  only  the  number  of  entries  as 
there  are  constraints  in  the  current  problem.  In  addition, 
in  the  operational  menu  ’ constraint  o’  is  replaced  by  the 
constraint  name  as  specified  when  the  problem  was  defined. 

The  user  should  select  the  constraint  that  he  wishes  to 
EDIT.  When  no  more  constraints  are  to  be  edited,  the  user 
should  enter  ’O’.  Control  will  be  returned  to  the  main 


problem  editing  menu.  Once  the  constraint  has  been  select¬ 
ed,  the  specific  coeff icient  that  is  to  be  modified  needs  to 
be  identified.  For  this,  the  following  menu  is  presented: 

EDIT  CONSTRAINT 

Following  are  the  constraint  coefficients  for  constraint  In:  nate 

1.  Coefficient  for  variable  xl  =  value 

2.  Coefficient  for  variable  x2  =  value 

3.  Coefficient  for  variable  x3  =  value 

• 

■ 

(repeated  for  each  decision  variable) 

Please  specify  the  nuaber  of  the  coefficient  that  you  would  like  to  change: 

(NOTE:  When  done  editing,  enter  "0*) 

"Constraint  will  indicate  the  number  of  the  selected 

constraint,  "nane"  will  indicate  that  constraint’s  name. 
In  addition,  the  menu  will  contain  one  entry  for  each  deci¬ 
sion  variable,  to  a  maximum  of  10.  The  user  should  select 
that  coefficient  he  wishes  to  edit.  When  no  more  coeffi¬ 
cients  of  this  constraint  are  to  be  changed,  the  user  should 
enter  "0".  He  will  then  be  given  the  option  of  editing 
other  objectives. 

If  the  user  decides  to  edit  one  of  the  coefficients  the 
following  menu  is  presented: 

Please  specify  the  new  coefficient  value: 

The  user  should  enter  the  new  constraint  coefficient  as  a 
floating  point  value.  After  entering  the  value  the  user  is 
given  the  option  to  edit  other  constraint  coefficients. 


Edit  Constraint  Right  Hand  Side.  This  -function 
is  used  to  alter  the  constraint  right  hand  side.  When 
selected,  a  menu  is  presented  as  follows: 

EDIT  CONSTRAINT 

1.  constraint  l 

2.  constraint-  2 

3.  constraint  J 

• 

(up  to  10  constraints) 

Please  specify  the  nuiber  of  the  constraint  whose  right  hand  side  you  would 
like  to  EDIT:  (NOTE:  If  you  are  done  °diting  right  hand  sides,  enter  '0“) 

The  above  menu  will  contain  only  the  number  of  entries  as 
there  are  constraints  in  the  current  problem.  In  addition, 
in  the  operational  menu  7  constrsint  n7  is  replaced  by  the 
constraint  name  as  specified  when  the  problem  was  defined. 

The  user  should  select  the  constraint  that  he  wants  to 
EDIT.  If  no  more  constraints  are  desired,  the  user  should 
enter  ’O’.  Once  the  desired  constraint  has  been  selected, 
the  new  right  hand  side  value  needs  to  be  specified.  For 
this,  the  following  menu  is  presented: 

The  right  hand  side  for  constraint  In  is  value 
Please  enter  the  new  right  hand  side  value: 

The  user  should  enter  the  new  right  hand  side  floating  point 
value.  After  entering  the  value,  the  user  will  be  given 
the  oppurtunity  to  specify  additional  constraints  that 


require  a  modification  to  the  right  hand  side. 
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Problem  Solving  Function 

The  problem  solving  -function  is  invoked  by  entering  “4" 
in  response  to  system  level  menu  #2.  Prior  to  selecting  the 
problem  solving  -function  users  should  have  completed  all 
necessary  problem  modi-f ications.  Once  invoked,  the  user 
should  select  from  the  two  available  problem  solving  meth¬ 
ods.  The  options  are  presented  in  the  following  menu: 

Please  specify  which  problea  solving  technique  you  now  wish  to  use  to  solve  the 
current  problea  (enter  ‘O*  to  exit): 

1.  The  weighting  technique 

2.  The  constraint  technique 

Which  Technique  to  Select.  First  time  users  may  be 
unsure  whether  they  should  select  the  weighting  or  the  con¬ 
straint  technique.  Since  they  both  generate  the  non-domin- 
ated  solution  set,  what’s  the  difference?  Simply  stated, 
the  weighting  technique  is  faster  but  will  generate  only 
corner  point  solutions  of  the  problem’s  feasible  region. 
The  constraint  technique  requires  more  computer  time  but  can 
generate  a  more  complete  solution  set.  In  addition,  since 
the  constraint  technique  optimizes  only  a  single  objective 
over  a  preset  range  of  values  for  the  other  objectives,  it 
is  necessary  to  have  some  prior  knowledge  of  the  legitimate 
range  of  the  other  objectives. 

Thus,  a  good  procedure  for  solving  new  problems  would 


be  to  first  use  the  weighting  technique  to  get  an  idea  of 
the  range  of  solutions  that  can  be  expected,  and  then  use 


the  constraint  technique  to  obtain  a  detailed  solution  set 
■from  the  desired  solution  interval. 

The  Weighting  Technique.  The  weighting  technique  will 
solve  a  series  o-f  single  objective  problems.  In  each  prob¬ 
lem,  the  aggregate  objective  is  formed  by  multiplying  each 
problem  objective  by  a  weight  and  summing  them  together. 
Each  solution  then  represents  the  optimal  allocation  of 
resources  for  that  specific  set  of  objective  weights.  When 
solved  over  the  complete  range  of  weights  for  each  objec¬ 
tive,  the  solution  set  will  reflect  optimal  solutions  for 
the  complete  range  of  priorities. 

The  time  required  for  PCADA  to  solve  a  problem  with  the 
weighting  technique  is  a  function  of  the  number  of  itera¬ 
tions.  PCADA  uses  only  objective  weight  combinations  that 
are  "naturally  normalized".  That  is,  weight  combinations 
that  sum  to  one.  The  number  of  iterations  is  determined  by 
number  of  objectives  and  the  user  selected  weight  increment 
as  follows: 


wei ght 
increment 

1 

- number  of 

2 

objecti ves- 
3 

4 

1 . 000 

1 

2 

3 

4 

0.500 

1 

3 

6 

10 

0.333 

1 

4 

10 

20 

0.250 

1 

5 

15 

35 

0.200 

1 

6 

21 

56 

0.  100 

1 

11 

66 

286 

0.050 

1 

21 

231 
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For  example,  the 

10  iterations  that 

are  required  for 

objectives  with  a 

weight 

increment  of 

0.333  would  use 

following  weight  combinations: 


Objective  weights 


Iteration 

1 

2 

3 

1 

0.000 

0.000 

1.000 

2 

0.000 

0.333 

0.667 

3 

0.000 

0.667 

0.333 

4 

0.000 

1 . 000 

0.000 

5 

0.  333 

0.000 

0.667 

6 

0.  333 

0.333 

0.333 

7 

0.333 

0.667 

0.000 

8 

0.667 

0.  000 

0.333 

9 

0.667 

0.333 

0.000 

10 

1.000 

0.000 

0.000 

As  can  be  seen,  the  number  of  iterations  can  easily  be¬ 
come  large.  Depending  on  problem  complexity  (i.e.  the  num¬ 
ber  of  decision  variables  and  constraints),  each  iteration 
will  require  from  2  to  9  seconds  of  computer  time.  Thus 
some  problems  will  require  up  to  an  hour  or  more  to  solve. 
Be  patient,  PCADA  will  tell  the  user  how  many  iterations  are 
required  and  will  keep  him  informed  of  solution  progress. 

Once  the  user  indicates  that  he  wants  to  use  the 
weighting  technique,  PCADA  will  present  the  following 
introductory  message: 

THE  WEIGHTING  TECHNIQUE 

The  weighting  technique  solves  the  probiea  by  assigning  weights  to  each  of  the 
separate  objectives,  foraing  a  new  objective,  and  optiaizing  it.  As  a  result, 
the  progra#  will  generate  a  'set*  of  solutions  with  each  one  corresponding  to  a 
different  weight  conbination.  These  'non-doainated'  solutions  will  be  output 
and  can  be  then  coapared  to  deteraine  which  one(s)  i stare)  appropriate. 

Next  the  user  will  be  presented  with  the  following  menu 


to  indicate  which  weighting  technique  option  is  desired: 


Please  select  fro*  the  following  weighting  technique  solution  options: 

(NOTE:  Enter  "0*  to  exit  the  weighting  technique) 

1.  Solve  with  specific  objective  weights 

2.  Solve  with  a  range  of  weights  on  all  objective  functions 

If  the  user  wants  to  solve  the  problem  once,  using  a 
specific  set  of  weights,  the  user  should  select  option  1. 
In  this  case,  the  program  will  next  ask  the  user  to  input 
the  desired  weights  -for  each  objective: 

Please  specify  the  weight  for  objective  t»:  nate 

During  program  execution  will  be  replaced  with  the 

sequential  objective  number  and  "objective  number"  will  be 
replaced  by  the  respective  objective  name  as  de-fined  by  the 
user  when  the  problem  was  de-fined.  The  program  will  accept 
any  input  -from  0.0  to  1.0  for  this  prompt.  It  is  not  re¬ 
quired  that  all  of  the  input  objective  weights  sum  to  1.0. 

At  this  point,  the  problem  is  solved  using  the  weights 
as  specified.  After  a  2  to  9  second  delay,  processing 
reverts  to  the  Presentation  of  Problem  Results  function 
which  is  described  below. 

If  instead  of  using  the  "solve  with  specific  weights" 
option,  the  user  would  like  to  examine  a  more  complete  sol¬ 
ution  set  covering  the  complete  range  of  objective  values, 
he  should  select  the  "range  of  weights"  option. 

When  solving  a  problem  with  a  range  of  weights,  PCADA 
will  automatically  generate  weight  values  which  will  cover 


the  complete  range  -from  0.0  to  1.0  for  all  objectives.  The 


user  though  must  specify  the  desired  weight  increment.  That 
is,  how  "fine"  of  a  change  in  the  aggregate  objective  is  the 
user  interested  in.  To  determine  the  desired  weight  incre¬ 
ment  the  PCADA  system  presents  the  following  menu: 

Please  specify  the  weight  incresent  to  be  used  for  this  solution: 

(NOTE:  Enter  *0*  to  exit  the  weighting  technique) 


1. 

1.000 

5. 

0.200 

2. 

0.500 

6. 

0.100 

3. 

0.333 

7. 

0.500 

4. 

0.250 

NOTE:  The  smaller  the  selected  increment,  the  more  itera- 
ations  and  longer  time  will  be  required  for  the  solution. 

At  this  point,  PCADA  will  attempt  to  solve  the  problem. 
Since  the  solution  may  require  considerable  time,  the  screen 
is  cleared  and  the  following  display  is  presented: 

— >  HULT I  OBJECTIVE  PROBLEM  SOLUTION  IN  PROCESS  <— 


PLEASE  BE  PATIENT' 

As  defined,  this  proble*  will  require,  nnn  linear  progra*  iterations. 

CURRENTLY  WORKING  ITERATION  t: 

XXX  *** 

The  item  "nr?n"  will  specify  how  many  iterations  are  needed 
and  “xxx"  will  indicate  which  iteration  is  currently  being 
worked.  At  the  completion  of  all  iterations  program 
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processing  reverts  to  the  result  presentation  -function. 

The  Constraint  Technique.  Like  the  weighting  tech¬ 
nique,  the  constraint  technique  will  solve  a  series  o-f  sin¬ 
gle  objective  problems.  Specifically,  all  but  one  o-f  the 
objectives  are  added  to  the  problem  as  equality  constraints. 
The  value  o-f  each  objectives  is  changed  -for  each  iteration 
and  the  optimum  value  o-f  the  other  objective  is  obtained. 
Thus  each  iteration  -finds  the  best  solution  given  preset 
values  -for  all  but  one  o-f  the  objectives. 

As  with  the  weighting  technique,  the  time  required  -for 
PCADA  to  process  the  constraint  technique  is  dependent  on 
the  number  o-f  iterations.  The  number  o-f  iterations  is 
easily  calculated  as  a  -function  o-f  the  number  o-f  objectives 
and  the  objective  range  increment  to  be  used  as  specified  by 
the  user.  The  number  of  iterations  is  calculated  by  raising 
the  objective  increment  to  the  number  of  objectives  —  1 
power.  For  example  a  problem  with  3  objectives  and  a  user 
specified  increment  of  10  will  require  10  x  10  =  100 
iterations.  The  number  of  iterations  is  highly  sensitive  to 
objective  increment. 

Once  the  user  has  indicated  his  desire  to  use  the 
constraint  technique,  PCADA  will  present  the  following 
introductory  message: 
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THE  CONSTRAINT  TECHNIQUE 


The  constraint  technique  solves  aultiobjective  probleas  by  asking  all  but  one  of 
the  objectives  into  equality  constraints  and  optiaizing  the  one  reaaining  ob¬ 
jective,  The  right  hand  sides  of  the  "nea*  constraints  are  bounded  by  the  user 
as  to  the  acceptable  upper  and  loiter  liaits.  These  right  hand  sides  are  then 
varied  betaeen  the  liaits  to  obtain  a  set  of  acceptable  solutions. 

At  this  point,  all  but  one  of  the  objectives  are  added 
to  the  problem  as  constraints.  PCADA  retains  the  first  ob¬ 
jective  as  the  one  to  be  optimized.  For  each  o-f  the  other 
objectives,  the  upper  limit,  lower  limit,  and  range  incre¬ 
ment  must  be  specified.  First,  PCADA  will  identify  the 
objective  to  be  optimized  as  follows: 

Objective  111  note  Mill  be  optiaized 

Then,  for  each  of  the  other  objectives  the  following  menus 
are  presented: 

—  OBJECTIVE  In:  naie  — 

Please  enter  the  upper  acceptable  liait  for  the  above  objective: 

For  this,  the  user  should  specify  the  highest  objective 
value  that  he  considers  to  be  appropriate.  Then: 

Please  enter  the  loMest  accepable  liait  for  the  objective  function  specified 
above; 

As  indicated,  the  lowest  acceptable  objective  value  should 
be  input.  Finally: 

Please  specify  the  nuaber  of  steps  for  solving  the  proble#  in  going  froa  the 
constraint  loaer  liait  to  the  upper  liait: 
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At  this  point  the  user  should  specify  the  increment  to  be 


used  in  going  from  the  lower  to  upper  limit.  The  smaller 
the  increment,  the  more  program  iterations  and  the  longer 
the  solution  time. 

Now,  PCADA  will  attempt  to  solve  the  problem.  Since 
the  solution  may  require  a  considerable  length  of  time,  the 
screen  is  cleared  and  the  following  display  is  presented: 

— >  MULTIOBJECTIVE  PROBLEM  SOLUTION  IN  PROCESS  <--- 

PLEASE  BE  PATIENT! 

As  defined,  this  problea  *ill  require,  nun  linear  prograa  iterations, 

CURRENTLY  WORKING  ITERATION  I: 

HI  XXX 

The  item  "nnn"  will  specify  how  many  iterations  are  needed 
and  "xxx"  will  indicate  which  iteration  is  currently  being 
solved.  At  the  completion  of  all  iterations,  program 
processing  reverts  to  the  result  presentation  function. 

Presentation  of  Problem  Results 

This  function  is  automat i cal  1 y  invoked  following  each 
execution  of  the  problem  solving  function.  The  purpose  of 
this  function  is  to  allow  the  user  to  examine  the  problem 
sol utions. 

Before  the  user  can  examine  the  non-domi nated  solution 


96 


set,  PCADA  will  in-form  the  user  o-f  any  special  or  unusual 
conditions  that  were  encountered  during  the  problem  solution 
phase.  A  summary  o-f  these  conditions  -follows. 

No  Bounded  or  Unbounded  Solutions  Found.  I-f  PCADA  de¬ 
tects  no  bounded  (that  is,  -feasible)  solutions  or  unbounded 
solutions,  the  user  is  so  in-formed  as  -follows: 

- >  Your  proble*  had  no  feasible  solutions  < - 

Check  for  error  in  forsulation  and/or  erroneous  constraints/objective  functions 
WHEN  READY  TO  CONTINUE,  PRESS  THE  RETURN  KEY 

As  indicated,  this  condition  probably  means  that  the  problem 
is  incorrectly  formulated.  If  it  is  correct,  then  with  the 
constraints  as  stated  there  is  no  solution.  That  is,  the 
constraints  cannot  be  satisfied.  Since  there  are  no  solu¬ 
tions  to  examine,  as  soon  as  the  user  acknowledges  the  above 
result  by  entering  the  return  key,  control  will  revert  to 
system  level  menu  2  for  problem  refinement  or  other  action. 

Unbounded  Solution  Detected.  In  the  event  that  PCADA 
detects  an  unbounded  solution,  the  program  will  take  one  of 
two  actions  depending  on  the  number  of  objectives.  If  there 
is  only  one  objective,  then  the  entire  solution  set  consists 
of  the  single  unbounded  solution.  The  user  is  informed  of 
this  case  as  follows: 

- >  Your  single  objective  problem  is  unbounded.  < - 

Check  for  error  in  forsulation  and/or  erroneous  constrai nts/ob j ect i ve  functions. 

WHEN  READY  TO  CONTINUE.  PRESS  THE  RETURN  KEY 


As  indicated,  this  condition  usually  means  that  the  problem 
is  incorrectly  -formulated  or  incorrectly  specified.  For 
example,  inadvertent  omission  of  a  constraint  could  easily 
explain  the  occurrance  of  an  unbounded  solution.  Sii.ce 
there  are  no  constraints  to  examine,  as  soon  as  the  user 
acknowledges  the  above  result  by  entering  the  return  key, 
control  will  revert  to  system  level  menu  #2  for  problem 
correction  or  other  action. 

If  there  is  more  than  one  objective,  then  PCADA  will 
inform  the  user  that  at  least  one  unbounded  solution  was 
detected.  It  will  also  display  the  weights  or  constraint 
limits  that  were  in  effect  when  the  first  unbounded  solution 
was  found.  To  inform  the  user  of  this  condition,  the 
following  display  is  generated: 

fit  least  one  unbounded  solution  Mas  obtained.  This  suggests  a  potential  proble* 
foraulation  error.  Please  check  your  problea  carefully.  The  unbounded  solution 
first  occurred  under  the  folloMing  conditions: 

OBJECTIVE  NEI6HT/LIHIT 

1.  Objective  In:  naae  Height 

•  i 

(repeated  for  each  objective) 

PRESS  THE  RETURN  KEY  HHEN  READY  TO  CONTINUE... 

When  the  user  acknowledges  the  above  result  by  entering  the 
return  key,  result  presentation  processing  continues  in 
order  to  display  all  other  detected  solutions  (if  any). 

Non-domi nated  Solution  Set.  Normally,  following  exe¬ 
cution  of  either  the  weighting  or  constraint  mul t i ob j ect i ve 
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techniques,  there  will  be  a  set  of  non-domi nated  solutions. 
This  section  describes  how  the  user  goes  about  viewing  this 
solution  set. 

First,  PCADA  will  inform  the  user  of  the  scope  of  the 
solution  set.  That  is,  the  number  of  entries  in  the 
solution  set  is  displayed  as  follows: 

There  were  n  NUN-DOMINATED  solutions  found. 

In  the  event  that  there  were  no  feasible  solutions  found, 
program  control  will  revert  to  system  level  menu  2  as 
before.  PCADA  can  only  handle  up  to  30  solutions.  If  more 
than  30  solutions  are  detected  given  the  user  specified 
solution  parameters,  the  user  is  informed  as  follows: 

- >  NOTE:  There  were  sore  than  the  program  Unit  of  30  solutions  < - 

The  first  30  NON-DONINATED  solutions  are  presented  in  what  follows.  To  get  the 
rest,  you  will  have  to  adjust  your  problem  and  solve  it  again.  Refer  to  the 
users  manual  for  further  information. 

The  user  will  still  be  able  to  examine  the  first  30 
solutions  in  the  usual  fashion  but  will  have  to  redefine  his 
solution  parameters  and  resolve  the  problem  to  obtain  the 
rest.  For  example,  users  may  resolve  the  problem  using  the 
constraint  technique  and  set  the  new  objective  points  (i.e. 
lowest  acceptable  value)  at  the  point  where  the  first  30 
solutions  stop. 

At  this  point,  the  user  is  presented  with  a  menu  which 
gives  him  the  various  solution  display  options  as  follows: 


Please  specify  your  choice  for  exaaining  problea  solutions: 
(NOTE:  Enter  "O'  to  exit  the  solution  display  sodule) 

1.  Objective  value  suaaary  —  all  solutions 

2.  Detailed  inforaation  —  one  specific  solution 

3.  Detailed  inforaation  —  all  solutions 


A  selection  of  option  1  will  result  in  a  display  o-f  just  the 
objective  values  that  result  -from  each  o-f  the  solutions. 
Figure  12  contains  an  example  o-f  this  display  -for  a  two  ob¬ 
jective  problem  with  10  solutions.  The  user  would  use  this 
display  to  quickly  see  the  range  of  objective  values  he  can 
expect  and  the  nature  of  objective  tradeoffs. 

If  the  user  selects  option  2,  he  will  be  presented  with 
the  details  concerning  one  solution  < which  the  user 
selects).  Detailed  solutions  include  objective  values, 
decision  variable  values,  constraint  si acks/surpl uses  and 
objective  weights  (if  requested  for  the  weighting  technique 


SUMMARY  OF  OBJECTIVE  VALUES  FOR  THE  NON-DOMINATED  SOLUTIONS 
OBJECTIVES  - 

SOLUTION  BOMBER  FIGHTER 


1  22.0000  14.0000 

2  21.0000  15.0000 

3  20.0000  16.0000 

4  19.0000  17.0000 

5  18.0000  18.0000 

6  17.0000  19.0000 

7  16.0000  20.0000 


Figure  12: 


Objective  Value  Summary 


NON-DOHINATED  SOLUTIONS  FOR  PROBLEM:  EXAMPLE 


***  SOLUTION  4  **» 

-  OBJECTIVES  - 

1.  BOMBER  =  19.0000 

2.  FI6HTER  =  17.0000 

-  VARIABLES  - 

Decision  variable  xl  =  7.0000 

Decision  variable  x2  =  5,0000 

-  CONSTRAINT  SLACKS/SURPLUSES  - 

Constraint  t  1  (  X1SUPPLY  )  had  a  SLACK  =  3.0000 

Constraint  «  2  (  X2SUPPLY  )  had  a  SLACK  =  3.0000 

Figure  13:  Detailed  Solution  Display 

only).  Figure  13  presents  a  sample  of  a  detailed  solution 
display.  When  the  user  selects  option  2,  PCADA  will  ask 
which  solution  is  desired  via  the  following  menu: 

Please  enter  the  nunber  of  the  solution  that  you  Mould  like  to  see: 

Solution  numbers  are  as  specified  in  the  objective  summary 
display. 

If  the  user  selects  display  option  3,  he  will  be  pre¬ 
sented  with  the  details  concerning  all  solutions.  Solution 
displays  are  presented  one  at  a  time  and  are  in  exactly  the 
same  format  as  shown  in  Figure  13. 

For  both  display  options  2  and  3,  if  the  solution  was 
obtained  via  the  weighting  technique,  the  user  is  asked  if 
he  would  like  the  display  to  include  the  objective  weights 
that  correspond  to  the  solution.  This  is  asked  using  the 
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following  menu: 


Would  you  like  your  solution  outputs  to  include  the  objective  weights  that  were 
used  to  obtain  the  corresponding  solution? 

1.  Yes 

2.  No 

If  the  user  selects  option  1  (yes)  then  the  detailed  solu- 
ion  displays  will  include  the  objective  weights  in  parenthe¬ 
ses  next  to  the  objective  value.  If  the  user  selects  option 
2  (no)  this  item  will  be  omitted  from  the  display  as  in 
Figure  13. 

For  all  displays,  the  system  will  ask  the  user  where  he 
would  like  'the  solution  displays  to  be  presented.  The 
following  menu  is  used  for  this  purpose: 

Please  indicate  the  desired  output  device  for  the  solutions! 

1.  Display  screen 

2.  Printer 

If  the  user  selects  option  2  (printer),  the  PCADA 
system  presents  the  following  instructional  message: 

»  TO  PRINT  THE  SOLUTIONS  « 

1.  Turn  on  the  printer 

2.  Set  the  printer  ’on-line* 

•3.  Align  the  paper 

WHEN  READY  TO  CONTINUE,  PRESS  THE  CARRIA6E  RETURN  *#♦ 

When  the  user  responds  by  pressing  the  carriage  return, 
printing  will  begin. 

If  the  user  requests  results  to  go  to  the  display 


screen,  the  screen  will  clear  and  output  will  begin. 

For  both  options  (printer  or  display  screen),  as  soon 
as  solution  presentation  is  completed,  the  user  will  be 


given  the  opportunity  to  continue  solution  examination 
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I  Introduction 


The  purpose  of  this  document  is  to  describe  the  PCADA 
software  package  to  the  level  of  detail  required  by  program¬ 
mers  and  analysts  who  may  wish  to  modify  and/or  expand  the 
program's  capabilities.  PCADA  was  programmed  in  such  a  way 
to  -facilitate  fault  isolation/correction  and  program  addi¬ 
tions.  That  is,  a  structured  consistent  approach  is  used 
throughout . 

Software  Environment 

PCADA  was  written  in  ANSI  standard  FORTRAN.  Specifi¬ 
cally,  Microsoft’s  FORTRAN-BO  on  an  Apple  11+  computer 
equipped  with  a  Z80  “softcard”  was  used  for  program  develop¬ 
ment.  However,  no  FORTRAN-80  or  Apple  unique  features  were 
utilised.  In  addition  to  FORTRAN-80,  the  program  develop¬ 
ment  process  required  the  usage  of  CP/M,  the  CP/M  editor, 
LINK-80,  amd  the  CP/M  Dynamic  Debugging  Tool  (DDT) . 

Programming  Conventions  and  Style 

The  twenty  four  program  modules  (one  main  program  and 
23  subroutines)  that  comprise  the  PCADA  system  were  all 
coded  using  a  consistent  style.  In  addition,  a  number  of 
helpful  coding  conventions  were  adopted  for  all  program 
modules. 

First,  to  facilitate  program  readability,  all  statement 
labels  appear  in  numerical  order.  As  an  example  of  this 
feature’s  usefulness,  when  examining  PCADA  listings,  ana- 


lysts  can  quickly  locate  speci-fic  sections  of  code  by  locat¬ 
ing  the  desired  label  in  its  correct  numerical  position. 

Second,  all  -format  statements  are  labeled  beginning 
with  900  and  continuing  sequentially  -from  there.  Also,  all 
format  statements  are  located  at  the  end  of  each  program 
module  rather  than  after  a  corresponding  read/write  state¬ 
ment  that  uses  the  format. 

Finally,  most  local  variables  are  explicitly  declared 
as  to  their  type.  This  feature  helps  prevent  errors  that 
can  occur  when  variables  default  to  what  may  be  an  incorrect 
implicit  type. 

Document  Outline 

Chapter  II  describes  the  structure  and  content  of  disk 
files  that  are  required  by  the  PCADA  system.  Common  blocks 
are  examined  in  detail  in  Chapter  III.  Included  is  a  common 
block  cross  reference  map.  Chapter  IV  presents  information 
relating  to  program  linkage.  In  addition  to  a  subroutine 
tree,  a  subroutine  cross  reference  map  is  presented.  A 
description  of  each  PCADA  module,  including  module  listings 
is  provided  in  Chapter  V.  Finally,  the  actual  menu  and  help 
data  that  is  used  throughout  PCADA  system  is  contained  in 


Chapter  VI. 


I I  Disk  Fi 1 es 


The  PCADA  system  utilizes  two  different  disk  -files. 
They  are,  the  menu/help  -file  and  the  user  de-fined  problem 
Tiles.  The  structure  and  content  o-f  these  -files  is 
described  in  this  chapter. 

It  should  be  noted  that  for  all  PCADA  disk  files, 
numeric  data  is  stored  on  disk  in  numeric  format.  It  is  not 
converted  to  character  format  for  disk  storage.  This  speeds 
disk  access  and  reduces  the  required  disk  storage  space.  In 
the  file  descriptions  which  follow,  where  applicable,  the 
FORTRAN  item  name  that  pertain  to  each  disk  file  item  is 
presented  in  paranthesis  following  the  item  description. 

The  Menu/Help  File 

To  help  accomplish  the  goal  of  a  system  that  is  user 
friendly,  detailed  and  lengthy  menu  and  help  information 
were  determined  to  be  essential.  Because  text  type  informa¬ 
tion  can  not  be  compressed,  that  is,  each  non-blank  charac¬ 
ter  requires  one  byte  of  storage  and  because  the  development 
system  was  limited  to  64K  of  memory,  it  was  decided  that  all 
menu  and  help  information  would  have  to  be  loaded  from  disk 
as  needed.  For  this  purpose,  the  menu/help  file  was 
created.  Whenever  a  menu  is  to  be  generated,  the  system 
loads  all  of  that  menu's  text  and  help  data  from  the 
menu/help  file  on  disk  into  the  menu/help  common  block. 

The  menu/help  disk  file  is  called  MENDAT.DAT  and  is 
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located  on  the  system  disk  that  is  expected  to  be  inserted 
into  disk  drive  #1.  When  PCADA  processing  begins,  the  main 
program  (PCADA)  assigns  logical  unit  #7  to  the  menu/help 
file.  No  PCADA  software  writes  to  the  menu/help  file  and 
only  one  routine  (PRSMEN)  reads  from  it. 

A  complete  listing  of  the  contents  of  the  menu/help 
file  is  presented  in  Chapter  VI.  The  remainder  of  this 
section  describes  the  structure  of  the  menu/help  file. 

CP/M  disk  files  consist  of  records  that  are  each  128 
bytes  in  length.  In  order  to  preserve  disk  space,  rather 
than  use  "screen  sized"  80  character  records,  trailing 
blanks  are  not  stored  and  sequential  menu  lines  are  concat¬ 
enated  on  the  disk  file.  Menu  size  and  format  information 
is  also  stored  to  provide  the  software  with  the  means  to 
regenerate  each  menu  when  needed. 

The  menu/help  file  can  be  thought  of  as  51  separate 
blocks  plus  one  control  record.  The  51  blocks  correspond  to 
the  51  menus  that  are  used  in  the  PCADA  system.  The  size  of 
each  of  these  blocks  is  variable  and  can  range  from  three  to 
seven  records  (each  record  is  123  bytes)  depending  on  the 
size  of  the  corresponding  menu.  The  control  record  is  the 
first  record  in  the  file.  This  record  is  not  used  by  the 
PCADA  operational  software.  It  does  provide  a  space  for 
keeping  track  of  file  version  number,  date  of  modification, 
and/or  number  of  active  records. 

Following  the  control  record,  the  separate  menu  blocks 


appear  sequentially.  The  first  record  of  each  menu  block 
contains  that  menu’s  control  information.  Following  is  a 
description  of  this  menu  control  information. 


BYTE  1:  The  number  of  records  containing  menu  data  for  this 
menu.  Menu  data  records  immediately  follow  the 

menu  control  record.  (MENSIZ) 

BYTE  2:  The  number  of  records  containing  help  data  for  this 
menu.  Help  data  records  immediately  follow  the 

menu  data  records.  (HLPSIZ) 

BYTE  3:  The  number  of  lines  that  are  required  by  the  menu 
when  output  to  the  video  display  screen.  This  item 
may  assume  any  value  from  one  to  twelve.  (MENL1N) 

BYTE  4:  The  number  of  lines  that  are  required  by  the  menu’s 
help  display  when  output  to  the  video  display 
screen.  This  item  may  assume  any  value  from  one  to 
twelve.  (HLPL1N) 

BYTES  5-16:  These  12  bytes  are  actually  12  separate  items 
each  of  which  corresponds  to  one  line  of  menu  data. 
If  the  menu  is  not  twelve  lines  long  then  not  all 
twelve  items  are  used.  For  example,  if  MENLIN  =  3, 
then  only  bytes  5,  6,  and  7  of  the  12  are  used. 
Each  byte  contains  the  length,  in  characters,  of 
the  corresponding  menu  line.  For  example,  if  byte 
5  =  69,  then  the  first  line  of  the  menu  has  69 

characters  in  it.  (MLNSZ) 

BYTES  17-28:  In  a  similar  fashion  to  the  above,  these  12 
bytes  contain  each  of  the  individual  line  sizes  for 
each  of  the  up  to  12  lines  of  help  data  that 
corresponds  to  the  menu.  (HLNSZ) 

BYTES  29-128:  Unused. 


Following  the  control  record  described  above,  the 
actual  menu  and  help  text  data  appears.  This  data  uses  a 
minimum  of  two  data  records  and  may  use  up  to  six.  The  six 
record  maximum  is  determined  by  the  size  of  the  common  block 
item  that  is  used  to  contain  menu/help  data  when  needed. 


The  item,  MENVAL  in  common  block  MENDAT  is  currently  sized 
to  accomodate  768  characters. 

Problem  Files 

Because  mul t i obj ecti ve  problems  are  generally  lengthy 
and  time  consuming  for  users  to  enter  into  the  program,  it 
was  decided  that  problem  data  would  be  automat i cal  1 y  saved 
on  disk.  When  storing  or  retrieving  problem  files,  the 
PCADA  system  assigns  logical  unit  #8  to  disk  drive  #2.  The 
system  uses  the  user  supplied  problem  name  concatenated  with 
the  file  type  “PRB"  as  the  problem  file  name. 

In  the  PCADA  system,  access  to  the  problem  files  is 
localized  to  just  two  subroutines.  GETPRB  is  called  when  an 
existing  problem  is  to  be  retrieved  and  SAVPRB  is  called  to 
store  the  problem  to  disk  following  definition  or  modifica¬ 
tion.  All  problem  data  that  is  stored  to  the  problem  file 
on  disk  is  contained  in  common  block  PROB  during  program 
execution. 

Each  problem  file  consists  of  three  separate  sections 
of  information.  The  first  section  contains  general  problem 
description  data.  This  data  is  contained  on  the  first 
record  in  the  problem  file.  The  following  information  is 
i ncl uded : 

BYTE  1:  The  number  of  constraints  in  the  problem.  Due  to 
program  limitations,  this  value  is  a  number  from  1 
to  10.  (NCON) 

BYTE  2:  The  number  of  objectives  in  the  problem.  Due  to 
program  limitations,  this  item  will  assume  a  value 
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between  1  and  4.  (NOBJ) 


BYTE  3:  The  number  o-f  variables  in  the  problem.  Due  to 

program  limitations,  this  item  will  assume  a  value 
between  1  and  10.  (NVAR) 

BYTES  4-128.  Unused. 


The  second  section  o-f  in-formation  contains  data 
pertaining  to  the  problem's  objectives.  This  section  will 
consist  o-f  up  to  -four  data  records.  The  actual  number  o-f 
objective  data  records  is  specified  by  NOBJ.  Each  objective 
data  record  contains  the  following  information: 


BYTES  1-8:  This  field  contains  the  user  assigned  objective 
name.  Names  are  limited  to  eight  characters. 

(ONAME) 

BYTE  9:  This  field  specifies  the  type  of  objective  that 
this  data  record  pertains  to.  Types  are  determined 
as  follows:  (OTYPE) 

1  =  MAXIMIZE 

2  =  MINIMIZE 

BYTES  10-49:  These  40  bytes  contain  the  objective  function 
coefficients.  Each  coefficient  requires  4  bytes, 
thus  space  for  10  coefficients  is  allocated.  This 
limit  corresponds  to  the  program  limit  of  10 
decision  variables.  For  each  problem,  NVAR 
specifies  the  actual  number  of  coefficents  that  are 
used.  Coefficient  data  is  stored  sequentially. 
For  example,  bytes  10  through  13  contain  the 
coefficient  for  variable  xl.  (OBJ) 

BYTES  50-128:  Unused. 


The  final  section  of  problem  information  is  the 
constraint  data.  This  section  follows  the  objective 
section  and  consists  of  one  data  record  for  each  constraint. 
There  can  be  up  to  10  constraint  data  records,  but  the 
actual  number  will  be  specified  by  NC0N.  Each  constraint 
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data  record  contains  the  -Foilwing  information  -fields: 


BYTES  1-8:  This  field  contains  the  user  assigned  constraint 

name.  Names  are  limited  to  eight  characters. 

(CNAME) 

BYTE  9:  This  field  specifies  the  type  of  constraint  that 
this  data  record  pertains  to.  Types  are  determined 
as  follows:  (CTYPE) 

1  =  less  than  or  equal 

2  =  equal 

3  =  greater  than  or  equal 

BYTES  10-49:  These  40  bytes  contain  the  constraint 
coef f icients.  Each  coefficient  requires  4  bytes, 
thus  space  for  10  coefficients  is  allocated.  This 
limit  corresponds  to  the  program  limit  of  10 
decision  variables.  For  each  problem,  NVAR 
specifies  the  actual  number  of  coefficents  that  are 
used.  Coefficient  data  is  stored  sequentially. 
For  example,  bytes  10  through  13  contain  the 
coefficient  for  variable  xl.  (CON) 

BYTES  50—53:  This  field  contains  the  constraint  right  hand 
side  value.  (RHS) 


BYTES  54—128.  Unused. 


Ill  Common  B1 ocks 


The  PCADA  software  package  uses  three  common  blocks  for 
the  storage  of  problem,  menu,  and  solution  data.  This 
chapter  presents  a  description  of  these  common  blocks  and  a 
cross  reference  map  showing  which  subroutines  use  which 
common  blocks. 

The  Problem  Common  Block 

Since  many  program  modules  in  the  PCADA  system  use 
problem  data  to  accomplish  their  tasks,  a  common  block  was 
created  to  contain  this  data  and  facilitate  the 
communication  of  it. 

COMMON  BLOCK  NAME:  PROB 
COMMON  BLOCK  SIZE:  737  Bytes 

Following  is  a  description  of  the  items  contained  in  common 
block  PROB. 

ITEM  NAME:  CON 

ITEM  TYPE:  REAL  ARRAY;  10  by  10  elements 

ITEM  DESCRIPTION:  CON  contains  the  constraint  coefficients 
for  the  problem.  The  10  by  10  size  reflects  the  fact 
that  the  program  is  limited  to  10  constraints  and  10 
decision  variables.  The  PCADA  system  limits  the  values 
that  CON  can  assume  to  the  range  -99999.0  to  +99999.0. 


ITEM  NAME:  CNAME 


ITEM  TYPE:  REAL*8  ARRAY;  10  elements 

ITEM  DESCRIPTION:  CNAME  contains  the  constraint  names.  The 
10  elements  reflect  the  fact  that  problems  are  limited 
to  10  constraints.  Constraint  names  are  optional,  and 
can  be  from  one  to  eight  alphanumeric  characters  in 
length. 


ITEM  NAME:  CTYPE 


ITEM  TYPE:  INTEGER*!  ARRAY;  10  elements 


ITEM  DESCRIPTION:  CTYPE  contains  the  constraint  types. 
There  are  three  different  types  allowed  and  they  are 
encoded  in  CTYPE  as  follows: 

1  =  less  than  or  equal 

2  =  equal 

3  =  greater  than  or  equal 

The  10  element  array  size  relects  the  fact  that  problems 
are  limited  to  10  constraints. 


ITEM  NAME:  RHS 

ITEM  TYPE:  REAL  ARRAY;  10  elements 

ITEM  DESCRIPTION:  RHS  contains  the  constraint  right  hand 
side  values.  The  10  element  size  reflects  the  fact  that 
problems  are  limited  to  10  constraints.  Constraint 
right  hand  side  values  are  must  be  non-negative  numbers 
less  than  99999.0. 


ITEM  NAME:  OBJ 

ITEM  TYPE:  REAL  ARRAY;  4  by  10  elements 

ITEM  DESCRIPTION:  OBJ  contains  the  objective  coefficients 
for  the  problem.  The  4  by  10  size  reflects  the  fact 
that  the  program  is  limited  to  4  objectives  and  10 
decision  variables.  The  PCADA  system  limits  the  values 
that  OBJ  can  assume  to  the  range  —99999.0  to  +99999.0. 


ITEM  NAME:  ONAME 


ITEM  TYPE:  REAL*8  ARRAY;  4  elements 

ITEM  DESCRIPTION:  ONAME  contains  the  objective  names.  The 
4  elements  reflect  the  fact  that  problems  are  limited 
to  4  objectives.  Objective  names  are  optional,  and  may 
be  from  one  to  eight  alphanumeric  characters  in  length. 


ITEM  NAME:  OTYPE 

ITEM  TYPE:  INTEGERS  ARRAY;  4  elements 

ITEM  DESCRIPTION:  OTYPE  contains  the  objective  types. 
There  are  two  different  types  allowed  and  they  are 
encoded  in  OTYPE  as  follows: 

1  =  MAXIMIZE 

2  =  MINIMIZE 

The  4  element  array  size  relects  the  fact  that  problems 
are  limited  to  4  objectives. 


ITEM  NAME:  NCON 
ITEM  TYPE:  INTEGERS 

ITEM  DESCRIPTION:  This  item  contains  the  number  of 
constraints  that  are  currently  part  of  the  problem 
description.  Because  of  system  limitations,  this  item 
will  assume  values  only  between  one  and  ten. 


ITEM  NAME:  NOBJ 
ITEM  TYPE:  INTEGERS 

ITEM  DESCRIPTION:  This  item  contains  the  number 
tives  that  are  currently  part  of  the  problem 
tion.  Because  of  system  limitations,  this 
assume  values  only  between  one  and  four. 


of  objec— 
descrip- 
item  will 


ITEM  NAME:  NVAR 


ITEM  TYPE:  INTEGERS 

ITEM  DESCRIPTION:  This  item  contains  the  number  o-f  varia¬ 
bles  that  are  currently  part  of  the  problem  description. 
Because  o-f  system  limitations,  this  item  will  assume 
values  only  between  one  and  ten. 


ITEM  NAME:  FNAME 
ITEM  TYPE:  REAL*8 

ITEM  DESCRIPTION:  This  item  contains  the  name  that  was 
assigned  by  the  user  to  the  current  problem.  This  item 
is  also  used  to  form  the  problem  file  name.  That  is,  to 
FNAME,  PCADA  concatenates  the  file  type  U.PRB"  before 
the  problem  is  saved  to  disk.  FNAME  is  a  required  input 
and  can  be  from  2  to  8  alphanumeric  characters  in 
length.  The  first  character  must  be  a  letter. 


The  Menu/help  Common  Block 

This  common  block  is  used  to  contain  menu  and  help  data 
for  the  current  menu.  Whenever  a  new  menu  is  required,  the 
subroutine  PRSMEN  loads  the  menu  data  into  the  common  block 
where  it  remains  active  until  a  different  menu  is  needed. 

COMMON  BLOCK  NAME:  MEND AT 
COMMON  BLOCK  SIZE:  798  Bytes 

Following  is  a  description  of  the  items  contained  in  common 
block  MEND AT. 
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ITEM  NAME:  MENS I Z 


i  ITEM  TYPE:  INTEGER*1 

ITEM  DESCRIPTION:  This  item  contains  the  number  of  records 
that  the  current  menu  occupies  on  disk.  Further  details 
concerning  this  item  can  be  found  in  the  previous 
chapter  which  describes  the  menu/help  disk  file. 

I 


ITEM  NAME:  MENLIN 
ITEM  TYPE:  INTEGERS 

ITEM  DESCRIPTION:  This  item  contains  the  number  of  lines 
that  the  current  menu  occupies  on  the  video  display 
screen.  Further  details  concerning  this  item  can  be 
found  in  the  previous  chapter  which  describes  the  menu/ 
help  disk  file. 


ITEM  NAME:  HLPSIZ 
ITEM  TYPE:  INTEGERS 

ITEM  DESCRIPTION:  This  item  contains  the  number  of  records 
that  the  help  data  which  corresponds  to  the  current  menu 
occupies  on  disk.  Further  details  concerning  this  item 
can  be  found  in  the  previous  chapter  which  describes  the 
menu/help  disk  file. 


ITEM  NAME:  HLPLIN 
ITEM  TYPE:  INTEGERS 

ITEM  DESCRIPTION:  This  item  contains  the  number  of  records 
that  the  help  data  that  corresponds  to  the  current  menu 
occupies  on  the  video  display  screen.  Further  details 
concerning  this  item  can  be  found  in  the  previous 
chapter  which  describes  the  menu/help  disk  file. 


ITEM  NAME:  MLNSZ 


ITEM  TYPE:  INTEGERS  ARRAY;  12  elements 

ITEM  DESCRIPTION:  MLNSZ  contains  the  size,  in  characters 
that  each  of  lines  in  the  current  menu  contains.  The 
item  is  used  to  unpack  the  menu  data  in  MENVAL  -for 
display.  The  12  elements  re-flect  the  -fact  that  PCADA 
limits  the  size  o-f  menus  to  12  lines. 


ITEM  NAME:  HLNSZ 

ITEM  TYPE:  INTEGER*1  ARRAY;  12  elements 

ITEM  DESCRIPTION:  HLNSZ  contains  the  size,  in  characters 
that  each  o-f  lines  in  the  help  data  that  corresponds  to 
the  current  menu  contains.  The  item  is  used  to  unpack 
the  help  data  in  MENVAL  -for  display.  As  with  menus, 
help  displays  are  limited  to  12  lines. 


ITEM  NAME:  MENVAL 

ITEM  TYPE:  LOGICAL  ARRAY;  768  elements 

ITEM  DESCRIPTION:  MENVALis  used  as  a  holding  area  tor  the 
actual  menu/help  character  data  that  is  presented  to  the 
user  on  the  video  display  screen.  It  is  loaded  by 
PRSMEN  directly  from  the  menu/help  file  on  disk.  The 
768  size  was  selected  to  accomodate  the  data  from 
exactly  six  disk  records  <128  characters  each).  The 
data  is  packed,  and  must  be  interpreted  by  PRSMEN.  The 
first  MENSIZ  times  128  characters  contains  the  menu  data 
and  the  next  HLPSIZ  times  128  characters  is  the  help 
data.  Trailing  blanks  are  not  stored. 


ITEM  NAME:  ACTMEN 
ITEM  TYPE:  INTEGER 

ITEM  DESCRIPTION:  This  item  contains  the  identification  of 
the  currently  active  menu.  Menus  are  identified  by  the 
starting  disk  record  number.  A  complete  listing  of 
PCADA  menus  and  help  information  is  provided  in  Chapter 
VI.  Included  are  the  menu  starting  record  numbers. 
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The  Solution  Common  Block 


Data  pertaining  to  the  problem  solution  is  stored  in  a 
common  block  that  is  available  to  the  many  PCADA  subroutines 
requiring  this  data.  The  data  in  this  common  block  is  set 
by  various  -functions  and  used  as  needed.  It  is  not  saved  to 
di  sk. 


COMMON  BLOCK  NAME:  SOLN 
COMMON  BLOCK  SIZE:  3953  Bytes 


The  items  contained  in  common  block  SOLN  are  described  in 
the  -following: 


ITEM  NAME:  W 

ITEM  TYPE:  REAL  ARRAY;  4  elements 

ITEM  DESCRIPTION:  This  item  contains  the  objective  weights 
or  constraint  limits  that  are  to  be  used  for  the  current 
solution  iteration.  If  the  weighting  technique  is  being 
used,  then  weights  are  stored  in  W,  otherwise  con¬ 
straints  are  stored.  W  is  set  iteratively  as  the  problem 
is  solved.  Each  element  of  this  array  corresponds  to 
one  of  the  objectives. 


ITEM  NAME:  UB 

ITEM  TYPE:  REAL  ARRAY:  4  elements 

ITEM  DESCRIPTION:  This  item  contains  the  objective  upper 
limit  to  be  used  in  solving  the  problem.  For  the 
weighting  technique  it  is  set  to  1.0,  for  the  constraint 
technique  it  is  set  to  the  user  specified  objective 
upper  limit.  When  the  problem  is  solved,  W  assumes 
values  between  LB  and  UB  using  the  increment  as 
specified  in  DEL. 
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ITEM  NAME:  LB 


ITEM  TYPE:  REAL  ARRAY: 


el ements 


ITEM  DESCRIPTION:  This  item  contains  the  objective  lower 
limit  to  be  used  in  solving  the  problem.  For  the 
weighting  technique  it  is  set  to  0.0,  -for  the  constraint 
technique  it  is  set  to  the  user  specified  objective 
lower  limit.  When  the  problem  is  solved,  W  assumes 
values  between  LB  and  UB  using  the  increment  as 
specified  in  DEL. 


ITEM  NAME:  DEL 


ITEM  TYPE:  REAL  ARRAY: 


el ements 


n 


ITEM  DESCRIPTION:  This  item  contains  the  objective  incre¬ 
ment  value  to  be  used  in  solving  the  problem.  For  both 
techniques,  this  item  is  set  to  the  increment  as 
specified  by  the  user.  When  the  problem  is  solved,  W 
assumes  values  between  LB  and  UB  using  the  increment  as 
specified  in  DEL. 


ITEM  NAME:  ISTRT 
ITEM  TYPE:  INTESER 

ITEM  DESCRIPTION:  This  item  specifies  which  solution 
technique  has  been  requested  by  the  user.  It  is  used  as 
f ol 1 ows: 

1  =  the  weighting  technique 

2  =  the  constraint  technique 


ITEM  NAME:  D 


ITEM  TYPE:  REAL  ARRAY;  10  by  31  elements 

ITEM  DESCRIPTION:  This  item  contains  the  constraint  coeffi¬ 
cients  as  used  by  the  linear  programming  subroutine. 
The  10  by  31  size  is  indicative  of  the  10  constraint 
limit  and  the  working  storage  required  by  the  LP 
subroutine. 


ITEM  NAME:  IBV 

ITEM  TYPE:  INTEGER  ARRAY;  10  elements 

ITEM  DESCRIPTION:  IBV  is  returned  from  the  linear  program 

subroutine  containing  the  identity  of  the  basic  varia¬ 
bles  that  are  in  the  solution.  For  example,  if  IBV(l) 
is  returned  equal  to  4,  then  x4  is  in  the  solution. 


ITEM  NAME:  SOLWHT 

ITEM  TYPE:  REAL  ARRAY;  30  by  4  elements 

ITEM  DESCRIPTION:  This  item  contains  the  objective  weights 
that  corresponds  to  each  non-domi nated  solution  that  is 
found.  This  item  is  used  only  for  the  weighting 
technique.  The  30  dimension  corresponds  to  the  fact 
that  PCADA  will  only  process  the  first  30  solutions. 


ITEM  NAME:  VARNUM 

ITEM  TYPE:  INTEGER*1  ARRAY;  30  by  10  elements 

ITEM  DESCRIPTION:  This  item  contains  the  values  that  are 
returned  from  the  linear  programming  subroutine  in  IBV. 
Whenever  the  solution  is  determined  to  be  of  the  non- 
domi  nated  variety,  PCADA  copies  IBV  to  VARNUM  in  order 
to  preserve  the  solution  for  further  processing.  The  30 
dimension  corresponds  to  the  fact  the  PCADA  will  retain 
only  the  first  30  solutions. 


ITEM  NAME:  VARVAL 


ITEM  TYPE:  REAL  ARRAY;  30  by  10  elements 

ITEM  DESCRIPTION:  This  item  contains  the  basic  variable 
values  that  are  returned  -from  the  linear  programming 
subroutine.  Whenever  the  solution  is  determined  to  be 
of  the  non— domi nated  variety,  PCADA  copies  the  solution 
to  VARVAL  in  order  to  preserve  the  solution  -for  -further 
processing.  The  30  dimension  corresponds  to  the  -fact 
the  PCADA  will  retain  only  the  -first  30  solutions. 


ITEM  NAME:  OBJVAL 

ITEM  TYPE:  REAL  ARRAY;  30  by  4  elements 

ITEM  DESCRIPTION:  This  item  contains  the  objective  values 
that  are  computed  by  PCADA  -following  each  linear  program 
iteration  whenever  the  solution  is  determined  to  be  o-f 
the  non— domi nated  variety,  PCADA  copies  the  objective 
values  to  OBJVAL  in  order  to  preserve  the  solution  -for 
-further  processing.  The  30  dimension  corresponds  to  the 
Tact  the  PCADA  will  retain  only  the  -first  30  solutions. 


ITEM  NAME:  ZF 

ITEM  TYPE:  REAL  ARRAY;  4  elements 

ITEM  DESCRIPTION:  This  4  element  array  is  used  as  a  tempo¬ 
rary  storage  area  for  objective  values  after  each  linear 
program  iteration.  When  the  solution  is  determined  to 
be  a  non-domi nated  solution,  the  values  in  ZF  are  moved 
to  OBJVAL. 


ITEM  NAME:  NNDS 
ITEM  TYPE:  INTEGER 

ITEM  DESCRIPTION:  This  item  contains  the  number  of  non- 
domi  nated  solutions  that  have  been  found.  It  is 

incremented  each  time  a  new  solution  is  found. 


I TEN  NAME 


CNXREF 


ITEM  TYPE:  INTEGERS  ARRAY;  10  elements 

ITEM  DESCRIPTION:  This  item  contains  cross  re-ference 
information  that  relates  the  constraint  data  in  D  to  the 
constraint  data  in  CON  (in  common  block  PROB) .  The  two 
arrays  are  not  kept  parallel  because  LP  requires  the 
constraints  to  be  presented  in  a  specific  order.  If 
CNXREF ( 1 )  equals  3,  it  means  that  D(l>  corresponds  to 
the  constraint  stored  in  C0N(3). 


ITEM  NAME:  SPCFLG 
ITEM  TYPE:  INTEGER*1 

ITEM  DESCRIPTION:  This  item  is  used  to  indicate  the 
occurance  of  a  special  condition.  A  value  of  zero  is 
default,  -1  indicates  that  at  least  one  infeasible 
solution  was  detected,  and  —2  means  that  at  least  one 
unbounded  solution  was  detected. 


ITEM  NAME:  UBWHT 

ITEM  TYPE:  REAL  ARRAY;  4  elements 

ITEM  DESCRIPTION:  If  an  unbounded  solution  is  detected, 

PCADA  will  inform  the  user  of  the  constraint/weight 
conditions  that  were  in  effect  when  the  solution  was 
found.  This  array  is  used  to  save  the  values  in  effect 
for  the  first  unbounded  solution. 


ITEM  NAME:  I CAP 
ITEM  TYPE:  INTEGER 

ITEM  DESCRIPTION:  This  item  is  set  to  a  non-zero  value 
whenever  more  than  30  non-domi nated  solutions  to  a 
problem  are  detected. 


IV  Program  Linkage 


This  chapter  presents  information  concerning  the 
program  linkage  for  the  PCADA  system.  First  a  subroutine 
tree  for  the  PCADA  software  package  is  presented.  The  tree 
appears  in  Figure  14  through  17.  Next,  a  subroutine  cross 
reference  map  is  provided  in  Figure  18.  This  map  is  useful 
to  programmers  when  it  is  necessary  to  determine  the  scope 
of  proposed  system  changes. 

Subroutine  Trees 


PCADA 


— PRSMEN 

-GETTXT - PRSMEN 

— PROHLP - PRTPRB - CDEL I N 

-GETANS  -PRSMEN 

-GET  I  NT - PRSMEN 

-PROHLP - PRTPRB - CDEL  I N 

-GETANS  -PRSMEN 

-DSKF'RB - GETTXT - PRSMEN 

-PROHLP - PRTPRB - CDEL  I N 

-GETANS  -PRSMEN 

GET  I  NT - PRSMEN 

PROHLP - PRTPRB - CDEL  I N 

-GETANS  -PRSMEN 

GETPRB - OPEN 

-NEWPRB - (see  FIGURE  15) 

-EDTPRB - (see  FIGURE  16) 

— PRBSLV - (see  FIGURE  17) 


Figure  14:  Top  level  Subroutine  Tree 
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NEWPRB - PRSMEN 

-GETTXT - PRSMEN 

-PRGHLP - PRTPRB - CDEL I N 

-GETANS  -PRSMEN 

— GETPRB 

-GETOBJ - GETTXT - PRSMEN 

— PROHLP - PRTPRB — 

-GETANS  -PRSMEN 

GET  I  NT - PRSMEN 

-PROHLP - PRTPRB — 

-GETANS  -PRSMEN 

GETFLT - PRSMEN 

-PROHLP - PRTPRB — 

-GETANS  -PRSMEN 

-GETINT - PRSMEN 

-PROHLP - PRTPRB - CDEL  I N 

-GETANS  -PRSMEN 

-GETCON - GETTXT - PRSMEN 

-PROHLP - PRTPRB — 

-GETANS  -PRSMEN 

GETINT - PRSMEN 

-PROHLP - PRTPRB — 

-GETANS  -PRSMEN 

GETFLT - PRSMEN 

-PROHLP - PRTPRB — 

-GETANS  -PRSMEN 

— SAVPRB 


— CDELIN 

— CDELIN 

— CDELIN 

— CDELIN 

— CDELIN 

— CDELIN 


Figure  1 


Define  New  Problem  Subroutine  Tree 


EDTPRB - PRSMEN 

-GETINT - PRSMEN 

— PROHLP - PRTPRB - CDEL I N 

-GETANS  -PRSMEN 

-GETOBJ - GETTXT - PRSMEN 

-PROHLP - PRTPRB - CDELIN 

-GETANS  -PRSMEN 

-GETINT - PRSMEN 

-PROHLP - PRTPRB - CDEL  I N 

-GETANS  -PRSMEN 

— GETFLT - PRSMEN 

-PROHLP - PRTPRB - CDEL  I N 

-GETANS  -PRSMEN 

-GETCON - GETTXT - PRSMEN 

-PROHLP - PRTPRB - CDEL  I N 

-GETANS  -PRSMEN 

-GETINT - PRSMEN 

-PROHLP - PRTPRB - CDEL  I N 

-GETANS  -PRSMEN 

-GETFLT - PRSMEN 

-PROHLP - PRTPRB - CDELIN 

-GETANS  -PRSMEN 

-GETTXT - PRSMEN 

-PROHLP - PRTPRB - CDEL  I N 

-GETANS  -PRSMEN 

-GETFLT - PRSMEN 

-PROHLP - PRTPRB - CDEL  I N 

-GETANS  -PRSMEN 

— SAVPRB 


Figure  16 


Problem  Modification  Subroutine  Tree 


-GETFLT - PRSMEN 

— PROHLP - PRTPRB - CDEL I N 

-GETANS  -PRSMEN 

-GET  I  NT - PRSMEN 

-PROHLP - PRTPRB - CDEL  I N 

-GETANS  -PRSMEN 

-PRSMEN 

-WSOLVE - CONMVE 

-LP 

-PROANS 

-SOLVE - WSOLVE - CONMVE 

-LP 

-PROANS 

— CSOLVE - CONMVE 

-LP 

-PROANS 

-CSOLVE - CONMVE 

-LP 

-PROANS 

-PRTANS - GET  I  NT - PRSMEN 

-PROHLP - PRTPRB - CDEL  I N 

-GETANS  -PRSMEN 

-GETTXT - PRSMEN 

-PROHLP - PRTPRB - CDEL  I N 

-GETANS  -PRSMEN 

-PRSMEN 


gure  17:  Problem  Solution  Subroutine  Tree 


V  V  V  \  V  V  \ 


Subroutine  Cross  Reference 


CCCDE6886866LNPPPPPPPSSW 
DOSSDEEEEEEEPECRRRRRRACS 
E  N  0  K  T  T  T  T  T  T  T  T  HABOQSTTVLO 
LMLPPACFIOPT  PDSAHMAPPVL 
IVERRNOLNBRX  RALNLEHRREV 
N  E  BBSNTTJBT  B  V  S  P  N  S  B  B  E 


CDELIN 

CONfIVE 

CSQLVE 

X 

X 

DSKPRB 

X 

X  X 

EDTPRB 

X  X 

X  X 

X 

X 

GETANS 

GETCON 

X 

X 

X 

6EIFLT 

X 

X 

X 

8ETINT 

X 

X 

X 

GETflBJ 

X 

X 

X 

GETPRB 

GETTn 

X 

X 

X 

LP 

NEWPRB 

X 

X  X 

X  X 

X 

PCADA 

X  X 

X 

X 

X  X 

X 

PR8SLV 

X 

X 

X 

X 

PR0ANS 

PSQHLP 

X 

PRSMEN 

PRTANS 

X 

X 

X 

PRTPRB 

X 

SAVPRB 

SOLVE 

X 

WSOLVE 

X 

X 

Figure  18:  Subroutine  Cross  Re-ference  Map 

To  determine  which  subroutines  are  called  by  a  particular 
module,  read  across.  To  determine  which  subroutines  call 


some  module,  read  down 


OPEL IN 


Code  Line 


t 

i 

I 


« 


i 
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Processing  Description.  Subroutine  CDELIN  is  a 
utility  -function  that  is  called  repeatedly  when  the  user  has 
requested  a  display  (either  printed  or  to  the  video  display 
screen)  o-f  his  current  problem.  The  purpose  o-f  CDELIN  is  to 
convert  -floating  point  constraint  or  objective  coe-f -f i ci ents 
into  the  appropriate  character  format  for  display.  After 
conversion,  CDELIN  inserts  the  converted  data  at  a  position 
in  the  output  line  buffer  as  specified  by  the  calling 
program. 

All  displays  that  involve  coefficients  also  display  the 
correspondi ng  variable  name  (i.e.,  xl).  For  this,  CDELIN 
also  converts  the  variable  number  and  stores  it  with  the 
corresponding  value.  A  12-character  field  is  used  by  CDELIN 
for  these  conversions.  The  first  nine  characters  contain 
the  character  representati on  of  the  floating  point  value, 
which  include  two  decimal  places,  and  the  sign.  The  last 
three  character  positions  consist  of  an  "x"  followed  by  the 
variable  number.  For  example,  the  following  is  a  typical 
CDELIN  conversion:  '*  -*-523.07x2  " . 

Key  Local  Variables.  Refer  to  the  module  listing. 


Module  Listing.  The  following 
FORTRAN  compilation  listing  of  CDELIN. 


pages  contain  the 


FORTRAN-BO  Ver.  3.43  Copyright  1978-1981  (0  By  Microsoft  --  Bytes:  25131 
Created:  27-Jun-81 

1  SUBROUTINE  CDELIN  (  FP,  LINE2,  1PNT,  J  ) 

2  C 

3  C  Subroutine  CDELIN  --  Code  line 

4  C 

5  C  This  subroutine  is  called  by  PRTPRB  to  foraat  a  floating  point  nu9ber 

6  C  and  place  it  in  a  logical  array  at  the  specified  point.  Floating 

7  C  point  nuibers  are  foraatted  in  a  12  character  space  as  follotts: 

8  C  The  first  nine  characters  contain  the  sign,  the  nuaber  (  including 

9  C  the  decimal  point  and  two  deciaal  digits  ).  NOTE:  Nuabers  pro- 

10  C  cessed  will  not  exceeed  99999.00  or  be  less  than  -99999.00.  The 

11  C  last  3  characters  contain  a  *x*  followed  by  the  variable  nuaber  as 

12  C  specified  in  the  calling  paraaeters.  All  unused  character  positions 

13  C  are  set  to  blank. 

14  C 

15  C  paraaeter  descriptions: 

16  C 

17  C  FP  --  Contains  the  floating  point  nuaber  that  is  to  be  foraatted. 

18  C  LINE2—  Is  the  (  up  to  48  character  )  array  that  will  recieve  the 

19  C  foraatted  value. 

20  C  IFNT  --  Is  a  pointer  to  the  starting  character  position  in  LINE2  that 

21  C  is  to  receive  the  foraatted  data. 

22  C  J  —  Is  the  variable  nuaber. 

23  C 

24  REAL  FP,  C0N(10,10),  0BJI4.10!,  RHS(IO) 

25  REAL+3  CNAMEU0),  0NAHE(4),  FNAME 

26  INTEGERS  CTYPE110),  DTYPEI4),  NCON,  NGBJ,  NVAR 

27  LOGICAL  LINE2I48),  ITEIH12) 

28  COMMON  /  PROB  /  CON,  CNAME.  CTYPE,  RH3,  OBJ,  0NAME,  0TYPE,  NC0N. 

29  1  N0BJ,  NVAR,  FNAME 

30  C 

31  C  Convert  the  floating  point  nuaber  to  ASCII 

32  C 

33  ENCODE  (  ITEM,  900  )  FP 

34  C 

35  C  Check  for  a  positive  value  and  if  positive,  search  for  the  first 

36  C  non  blank  character  position  for  insertion  of  the  '+*  sign. 

37  C 

38  IF  (  FP  .LT.  0.0  )  80  TO  15 

39  DO  10  K  =  1,  9 

40  IF  (  ITEM(K)  , EQ.  32  )  GO  TO  10 

41  II  =  K  -  1 

42  ITEM (II)  =  43 

43  GO  TO  15 

44  10  CONTINUE 

45  15  CONTINUE 

46  C 

47  C  Store  the  'V  and  the  variable  nuaber 

48  C 


ITEM  f 10)  =  120 


50  ITEM (11)  =  J  +48 

51  ITEH(12>  =  32 

52  IF  (  J  .NE.  10  )  60  TO  18 

53  ITEH(ll)  =  49 

54  ITEHI12)  =  48 

55  18  CONTINUE 

56  C 

57  C  Move  the  foriatteo  item  to  the  output  array 

53  C 

59  DO  20  K  =  1,  12 

60  LINE2UPNT)  =  ITEMiK) 

61  IPNT  =  IPNT  +  1 

62  20  CONTINUE 

63  C 

64  C  Increeent  the  pointer  to  the  output  array. 

65  C 

66  900  FORMAT  (  F9.2  ) 

67  RETURN 

68  END 

Progras  Unit  Length=00F5  (245)  Bytes 
Data  Area  Length=0022  (34)  Bytes 

Subroutines  Referenced: 

*11  *AT  *QE 

*ND  111 


Variables'. 


FP 

0001' 

LINE2 

0003* 

IPNT 

0005* 

J 

0007' 

CON 

/PR0B/+0000 

OBJ 

/PR08/+0212 

RH5 

/PR0B/+01EA 

CNAME 

/PRQB/+0190 

0NAME 

/PRGB/+02B2 

FNAME 

/PRQB/+02D9 

CTVPE 

/PR08/+01E0 

OTYPE 

/PR0B/+02D2 

NCON 

/PROS/ +0206 

N0BJ 

/PR08/+02C7 

NVAR 

/PR0B/+02D8 

ITEM 

0009" 

T: 000002 

!  0015* 

K 

0016* 

II 

O 

o* 

CO 

T: oooooo 

001A* 

COMMON  Length 
/PRG8/02E1  (737) 

Labels: 

900L  001C*  15L  0074’  10L  0067’ 

18L  00B2'  20L  OOE3’ 


CONMVE  —  hove  Constraint 

Processing  Description.  The  linear  programming  sub¬ 
routine  (LP>  used  by  PCADA  requires  that  the  problem  con¬ 
straints  be  ordered  according  to  type.  The  greater  than  or 
equal  constraints  must  be  -first,  the  equality  constraints 
second,  and  the  less  than  or  equal  constraints  last.  Since 
PCADA  does  not  require  users  to  enter  the  constraints  in  any 
particular  order  and  since  constraints  are  maintained  inter¬ 
nally  in  the  order  entered  rather  than  by  type,  the  con¬ 
straints  must  be  reordered  prior  to  calling  LP.  The  reor 
dering  process  takes  place  as  the  constraints  are  moved 
from  the  problem  array  CON  to  the  LP  constraint  array  D  for 
solution  processing.  CONMVE  is  called  to  scan  CTYPE,  which 
is  parallel  to  CON,  for  constraints  of  the  type  specified  by 
the  calling  program  and  then  move  them  to  D  begining  at  the 
entry  specified  by  the  calling  program.  Prior  to  each 
solution,  CONMVE  is  called  three  times.  First  to  scan  CTYPE 
for  greater  than  or  equal  constraints,  second  for  equality 
constraints  and  third  for  less  than  or  equal  constraints. 
CONMVE  also  counts  how  many  constraints  were  moved  and 
returns  that  information  back  to  the  calling  program. 

Key  Local  Variables.  Refer  to  the  module  listing. 

Module  Listing.  The  fallowing  pages  contain  the 


FORTRAN  compilation  listing  for  CONMVE. 


FQRTRAN-80  Ver.  3.43  Copyright  1978-1981  (C)  8v  Microsoft  --  Bytes:  25131 
Created:  27-Jun-81 

1  SUBROUTINE  CONMVE  (  ITYPE,  ICNT,  11  ) 

2  C 

3  C  Subroutine  CONMVE  --  Move  constraint 

4  C 

5  C  This  subroutine  aoves  constraints  fro*  the  PROB  coeion  block  to  the 

6  C  SOLN  coa*on  block.  It  is  called  repeatedly  by  SfSQLVE  and  CSOLVE  in 

7  C  preparation  for  probles  solution.  Each  tiae  it  is  called,  it  scans 

8  C  the  constraints  for  those  constraints  whose  type  (CTYPE)  Batches 

9  C  ITYPE.  It  aoves  such  constraints  into  D  sequentially  beginning  at 

10  C  the  entry  indicated  by  II.  The  subroutine  also  keeps  track  of  how 

11  C  sany  constraints  have  Batched  the  specified  type  and  have  been  soved. 

12  C 

13  C  Paraaeter  descriptions  - 

14  C 

15  C  ITYPE  --  Identifies  the  type  of  constraint  that  is  to  be  aoved  during 

16  C  this  call.  Types  are:  1  =  less  than  or  equal: 

17  C  2  =  equal! 

18  C  3  =  greater  than  or  equal. 

19  C  ICNT  --  Contains  the  count  of  how  sany  constraints  were  aoved  froa 

20  C  PROS  to  SOLN. 

21  C  II  --  Input  and  output  as  a  pointer  to  the  arrays  in  SOLN  that 

22  C  recieve  the  constraint  data,  in  both  cases,  this  itea  con- 

23  C  tains  the  next  available  entry. 

24  C 

25  REAL  N(4),  UB(4),  LB!4),  DELI4),  P(30),  D(10,31> 

26  REAL  IF  14) ,  06JVALI30,4),  VARVAU30, 10) 

27  REAL  SOLNHT (30,4) ,  UBWHT(4) 

28  REAL  CONdO,  10) ,  0BJ!4,10),  RHS(IO) 

29  REALtS  CNAME(IO),  QNANE(4) ,  FNAME 

30  INTEGERS  SPCFL8,  VARNUM(30, 10) ,  CNXREF(IO) 

31  INTEGERS  CTYPE(IO),  0TYPE<4>,  NCON,  NOBJ,  NVAR 

32  INTEGER  IBV(IO) 

33  COMMON  /  PROB  /  CON,  CNAME,  CTYPE,  RHS,  OBJ,  ONAME,  QTYPE,  NCON, 

34  1  NOBJ,  NVAR.  FNAME 

35  COMMON  /  SOLN  /  H,  UB,  LB,  DEL,  ISTRT,  P,  D,  IBV,  SOLWHT,  VARNUM, 

36  1  VARVAL,  OBJVAL,  ZF,  NNDS,  CNXREF ,  SPCFLG,  UBHHT, 

37  2  ICAP 

38  C 

39  C  initialize  ICNT  to  indicate  that  no  constraints  were  aoved. 

40  C 

41  ICNT  =  0 

42  C 

43  C  enter  loop  to  search  CTYPE  for  constraints  of  the  appropriate  tvpe. 

44  C 

45  DO  100  I  =  1.  NCON 

46  IF  (  CTYPEII)  .NE.  ITYPE  )  60  TO  100 

47  C 

48  C  for  constraints  of  the  appropriate  type,  enter  loop  to  aove  the  con- 

49  C  straint  coefficients  froa  CON  <  in  PROB  )  to  D  (  in  SOLN  ). 
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50  C 

51  CN1REFUI)  =  1 

52  DO  50  J  =  1,  NVAR 

53  D(II.J)  =  CQM(IJ) 

54  50  CONTINUE 

55  C 

56  C  *ove  the  constraints  right  hand  side  value  froa  RHS  (  in  PROS  )  to  D 

57  C  (  in  SOLN  ). 

50  C 

59  Dili, 31)  =  RHS(I) 

60  C 

61  C  increaent  the  pointer  to  D  !  in  SOLN  ! 

62  C 

63  II  =  II  +  1 

64  C 

65  C  incre#ent  the  count  of  the  nuaber  of  constraints  that  were  soved, 

66  C 

67  ICNT  =  ICNT  +  1 

68  100  CONTINUE 

69  RETURN 

70  END 

Prograa  Unit  Length-OlOC  (268)  Bytes 
Data  Area  Length=0014  (20)  Bytes 


Variables: 


I  TYPE  0001' 

*  /S0LN/+0000 

DEL  /SOLN/ +0030 

ZF  /SQLN/+QF42 

SQLWHT  /SOLN/+05A6 

OBJ  /PRQB/+0212 

ONANE  /PR08/+02B2 

VARNUM  /SQLN/+0786 

OTYPE  /PR0B/+-02D2 

NVAR  /PRG8/+02D8 

NNDS  /S0LN/+0F52 

T: 000002  0009* 

T: 010000  000E  * 


ICNT 

0003* 

UB 

/SQLN/+0010 

P 

/SQLN/+0042 

OBJVAL 

/S0LN/+0D62 

UBNHT 

/S0LN/+0F5F 

RHS 

/PRQB/+01EA 

FNAME 

/PR0B/+02D9 

CNXREF 

/S0LN/+0F54 

NCON 

/PR0B/+02D6 

I6V 

/S0LN./+0592 

ICAP 

/S0LN/+0F6F 

T:ooooo( 

)  OOOA 

T.-02000C 

i  0010' 

II  0005 1 

LB  /SOLN/ +0020 

D  /S0LN/+00BA 

VARVAL  /SQLN/+08B2 

CON  /PR0B/+0000 

CNAflE  /PR0B/+0190 

SPCFLB  /S0LN/+0F5E 

CTYPE  /PRQB/+01E0 

NOBJ  /PRQB/+Q2D7 

ISTRT  /S0LN/+0040 

I  0007’ 

J  OOOC" 

T: 030000  0012’ 


COMMON  Length 

/PR0B/02E1  (737) 

/S0LN/0F71  (3953) 

Labels: 

100L  OOF7 ’  SOL  00A3’ 
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Processing  Description.  This  module  is  responsible 
•for  calling  the  linear  programming  subroutine  (LP>  to  obtain 
a  problem  solution  using  the  constraint  technique.  Prior  to 
invoking  CSOLVE,  SOLVE  has  determined  -from  the  user  the 
desired  constraint  limits  and  increments.  CSOLVE  then  sets 
up  the  problem  in  the  format  required  by  LP,  and  then  calls 
LP  for  solution.  Included  in  CSOLVE7 s  set  up  process  is  to 
include  all  but  the  first  objectives  as  equality  con¬ 
straints.  For  these,  the  constraint  limit  is  determined  by 
SOLVE  prior  to  the  call  to  CSOLVE.  Following  the  call  to 
the  linear  programming  package,  PROAixS  is  called  to  examine 
the  LP  solution  to  determine  if  it  should  be  included  in  the 
non-dorainated  solution  set.  CSOLVE  is  called  once  by  SOLVE 
for  each  iteration.  The  number  of  iterations  is  determined 
by  the  constraint  limits  and  increments  as  specified  by  the 
user . 

Key  Local  Variables. 

IMULT  —  Flag  that  is  used  to  convert  objective  coefficients 
when  the  objective  is  to  be  minimized.  That  is, 
since  LP  only  maximizes,  for  objectives  to  be 
minimized,  the  coefficients  need  to  be  multiplied 
by  minus  1.  For  minimize  problems,  IMULT  will 
assume  the  value  of  -1,  for  maximize  problems,  it 
will  be  set  to  1. 

Module  Listing.  The  following  pages  contain  the 


FORTRAN  compilation  listing  of  CSOLVE. 


FORTRAN-SQ  Ver.  3.4J  Copyright  1978-1991  (0  Bv  Microsoft  -  Bytes:  25131 
Created:  27-Jun-81 

1  SUBROUTINE  CSOLVE 

2  C 

3  C  Subroutine  CSOLVE  —  Solve  problea  using  the  constraint  technique 

4  C 

5  C  This  subroutine  processes  probless  for  solution  using  the  constraint 

6  C  technique.  It  is  called  by  SOLVE  to  iteratively  call  LP  nith  the 

7  C  different  problea  foraulations  for  finding  the  non-doainated  sol - 

8  C  utions.  Prior  to  calling  this  subroutine,  SOLVE  has  deterained 

9  C  the  constraint  liaits  and  the  nusber  of  steps  to  go  between  thes, 

10  C  After  each  call  to  LP,  this  prograa  saves  the  results  and  coapares 

11  C  thea  to  obtain  the  set  of  nondoainated  solutions. 

12  C 

13  C  This  subroutine  has  no  calling  paraaeters. 

14  C 

15  REAL  «(4>,  UBI4),  LB(4),  DEL (4),  CQN(IO.IO),  OBJ (4, 10) ,  RHS(IO) 

16  REAL  P (30) ,  DUO, 31) 

17  REAL  SOLMHT (30, 4) ,  UBWHT ( 4 ) 

13  REAL  ZF(4) ,  0BJVAL(30,4) ,  VARVALI30, 10) 

19  INTEGER  IBVilO) 

20  REAL *8  CNAMEU0),  0NAME(4),  FNAME 

21  INTESER*1  CTYPEU0),' 0TYPE (4) ,  NC0N,  N0BJ,  NVAR 

22  INTEGER*!  SPCFLS,  VARNUH130, 10),  CNXREFUO) 

23  C0NM0N  /  PROB  /  CON,  C-NAHE ,  CTYPE,  RHS,  OBJ,  DNAME.  OTYPE,  NCON. 

24  1  NOBJ,  NVAR,  FNAHE 

25  COMMON  /  SOLN  /  N.  UB,  LB,  DEL,  ISTRT,  P,  D.  IBV.  SOLNHT,  VARNUM, 

26  l  VARVAL.  OBJVAL,  ZF,  NNDS,  CNXREF,  SPCFLS,  UBWHT, 

27  2  1CAP 

28  C 

29  C  set  IMULT  to  -1  if  the  objective  is  ainisize,  otherwise,  set  it  to 

30  C  1.  This  is  necessary  because  LP  processes  only  MAXIMIZE  probleas. 

31  C 

32  IMULT  =  1 

33  IF  (  OTYPE (1)  ,E9.  2  )  IMULT  =  -1 

34  C 

C  enter  loop  to  aove  the  objective  coefficients  froa  OBJ  (  in  PROB  )  to 
2u  C  P  (  in  SOLN  ). 

37  C 

38  DO  100  I  =  1,  NVAR 

39  Pfl)  =  OBJ (1,1)  *  IMULT 

40  100  CONTINUE 

41  C 

42  C  initialize  the  pointer  to  the  constraint  array,  D  (  in  SOLN  ). 


C  call  CONMVE  to  aove  the  greater  than  or  equal  constraints  froa  CON 
C  (  in  PROB  )  to  D  (  in  SOLN  ). 


CALL  CONMVE  (  3,  IA,  II  ) 


140 


51 

52 


C 

C  enter  loop  to  sove  the  resaining  oojectives  into  the  constraint  array 


c*? 

J.» 

C 

as  ‘equal*  constraints. 

54 

C 

55 

DO  200  1  =  2.  NOBJ 

54 

D ( 1 I ,3 1)  =  H(I> 

57 

DO  150  3=1,  NVAR 

53 

D ( 1 I , J )  =  OBJ (I, J) 

59 

150  CONTINUE 

40 

II  =  II  ♦  1 

61 

200  CONTINUE 

62 

210  CONTINUE 

63 

C 

64 

C 

call  CONMVE  to  aove  the  ‘equal*  constraints  fro*  CON  (  in  PROB  )  to 

65 

C 

D  (  in  SOLN  ). 

66 

c 

67 

CALL  CONMVE  (  2.  NEQ,  II  ) 

68 

c 

69 

c 

set  NEQ  equal  to  the  nusber  of  equal  constraints... reaesber,  this 

70 

c 

includes  the  real  equal  constraints  AND  all  but  one  of  the 

71 

c 

objectives  (  that  have  been  processed  into  equal  constraints  ). 

72 

c 

73 

NEQ  =  NEQ  +  NOBJ  -  1 

74 

c 

75 

c 

call  CONMVE  to  aove  the  'less  than  or  equal"  constraints  froa  CON 

76 

c 

(  in  PROS  )  to  D  (  in  SOLN  ). 

77 

c 

78 

CALL  CONMVE  (  1.  IX.  II  ) 

79 

c 

80 

c 

set  the  nusber  of  constraints 

81 

c 

82 

IN  =  NCQN  +  NOBJ  -  1 

83 

c 

84 

c 

set  the  nusber  of  variables. 

85 

c 

86 

IY  =  NVAR  +  ! 

87 

c 

88 

c 

set  the  nusber  of  satrix  colusns,  including  one  for  the  right  hand 

89 

c 

side. 

90 

c 

91 

12  =  IY  +  NEQ  +  IX  +  (  2  *  IA  ) 

92 

c 

93 

c 

call  LP  to  get  the  solution  to  the  current  forsuiation. 

94 

c 

95 

CALL  LP  1  IN,  IZ,  IY,  IA,  NEQ  ) 

96 

CALL  PROANS  (  IZ,  IN  ) 

97 

RETURN 

98 

END 

Progras 

Unit  Length=013D  (397)  Bytes 

Data  Area  Length=0022  (34)  Bytes 

Subroutines  Referenced: 


*L1  $MA  $TI 
CONHVE  $M9  LP 
PSOANS 

Variables: 


w 

/SQLN/+0000 

UB 

7SQLN/+0010 

LB 

/SQLN/+0020 

DEL 

7 SOLN 7+ 0030 

CON 

/PROS  7+0000 

OBJ 

/PR0B./+O212 

RHS 

7PR08/+01EA 

P 

/S0LN/+0042 

D 

/S0LN7+00BA 

SOLSHT 

7SOLN/+05A6 

UBWHT 

/S0LN/+0F5F 

ZF 

/S0LN7+0F42 

OBJ VAL 

/S0LN/+0D62 

VARVAL 

/S0LN/+C8B2 

IBV 

/SOLN 7+0592 

CNAME 

/PR08/+0190 

ONAME 

/P8GB/+02B2 

FNAME 

7PR0B/+02B9 

CIYPE 

/PR0B/+O1E0 

OTVPE 

/PRQB7+02D2 

NOON 

/PR0B/+02C6 

NGBJ 

/PR0B/+02D7 

NVAR 

7PS0B/+02D8 

SPCFLB 

7S0LN/+0F5E 

VARNUH 

/S0LN/+0786 

CN.XREF 

7S0LN/+0F54 

ISTRT 

./SOLN/  +0040 

NNDS 

/S0LN/+0F52 

I  CAP 

/S0LN/+0F4F 

I  MULT 

ooo  r 

T : 000002 

:  0003* 

I 

0004* 

T:  000000  OOOl 

II 

0008' 

IA 

000 A* 

J 

oooc* 

T: 010000 

000E  ‘ 

T : 020000 

i  0010* 

NE3 

0012* 

n 

0014“ 

1(4 

0016" 

IY 

CO  IS" 

12  00 1 A" 

COMMON  Length 

7PR08/02E1  (737) 
/S0LN/0F71  (3953) 


I'-J  ho 


DSKPRB  —  Retrieve  Problem  -from  Disk 

Processing  Description.  All  problems  defined  by  users 
with  PCADA  are  automatically  saved  to  disk  when  they  are  de¬ 
fined.  In  order  to  retrieve  them,  the  PCADA  system  includes 
the  necessary  software  functions  to  retrieve  and  store  prob¬ 
lem  disk  files.  These  functions  are  isolated  to  two  program 
modules.  SAVPRB  is  used  to  store  problem  files  on  disk  and 
GETPRB  is  used  to  retrieve  problem  files  from  disk.  Prior 
to  invoking  GETPRB  to  retrieve  a  problem  file,  DSKPRB  is 
called  to  ask  the  user  to  identify  the  desired  file  by  name. 
After  obtaining  the  user’s  response,  GETPRB  is  called.  If 
GETPRB  encounters  some  kind  of  input/output  error  that 
prevents  the  loading  of  the  requested  file,  DSKPRB  informs 
the  user  and  asks  him  if  he  wants  to  try  again.  If  the  user 
responds  yes,  the  process  is  repeated,  otherwise  control 
reverts  to  the  calling  program. 

Key  Local  Variables.  Refer  to  module  listing. 

Module  Listing.  The  following  pages  contain  the 


FORTRAN-80  Ver.  3,43  Copyright  1973-1981  (0  By  Microsoft  --  Bytes:  25131 
Created:  27-Jun-Bl 

1  SUBROUTINE  DSKPSB 

2  C 

3  C  Subroutine  DSKPRB  --  Retrieve  problea  fro*  disk 

4  C 

5  C  This  subroutine  is  designed  to  obtain  e  previously  defined  problea 

6  C  fro*  a  disk  file  and  load  it  into  the  coiaon  block  /  PROB  /.  Disk 

7  C  files  containing  probleis  sust  be  installed  in  disk  drive  nuaber  2. 

8  C  Also,  problea  file  naaes  are  xxxxxxxx.PRB  where  xxxxxxxx  is  defined 

9  C  by  the  user.  DSKPRB  will  return  control  only  after  a  problea  has 

10  C  been  load  or  after  the  user  has  expressed  his  desire  to  not  load  a 

11  C  problea. 

12  C 

13  C  there  are  no  input/output  paraaeters  for  this  subroutine 

14  C 

15  LOGICAL  TXTVAL (32) ,  NAME (8) 

16  REAL*8  CNAME(IO),  0NAME(4),  FNAME 

17  INTEGERS  CTYPEilO).  OTVPE <4) ,  NCON,  NOBJ,  NVAR 

18  REAL  CON (10, 10),  0BJ(4,10),  RHS(IO) 

19  COHMON  /  PROB  /  CON,  CNAME,  CTYPE,  RH5,  OBJ,  ONAME.  OTYPE,  NCON, 

20  1  NOBJ,  NVAR,  FNAME 

21  EQUIVALENCE  (  TXTVAL(l),  NAME(l)  ) 

22  5  CONTINUE 

23  C 

24  C  Ask  the  user  for  a  filenaae  via  6ETTXT,  note:  filenaaes  can  be  froa 

25  C  two  to  eight  characters  in  length,  the  user  need  not  specify  the 

26  C  ,PR8\ 

27  C 

28  CALL  GETTXT  (  36,  0.  8,  2,  TXTVAL.  0  ) 

29  C 

30  C  Call  GETPRB  to  atteapt  to  retrieve  the  reguested  file  froa  disk. 

31  C  Upon  return,  ISTAT  indicates  if  the  retrieval  was  successful. 

32  C 

33  CALL  GETPRB  (  NAME,  ISTAT  ) 

34  C 

35  C  At  this  point,  an  ISTAT  value  of  1  indicates  soae  disk  problea  has 

36  C  occurred. 

37  C 

38  IF  (  ISTAT  .NE.  1  )  GO  TO  9999 

39  C 

40  C  Info r*  the  user  that  a  problea  has  occured,  give  him  the  options, 

41  C  and  ask  hia  if  he  wants  to  try  again. 

42  C 

43  CALL  6ETINT  (  42.  0,  2,  1,  INTVAL  ) 

44  C 

45  C  A  user  response  of  one  (INTVAL)  indicates  that  the  user  understands 

46  C  the  problea  and  wants  to  try  again,  check  for  one  and  branch  back 

47  C  to  try  again. 

48  C 

49 


IF  (  INTVAL  . EQ.  1  )  60  TO  5 


50  9999  CONTINUE 

51  RETURN 

52  END 

Progras  Unit  Length=0062  (98)  Bytes 
Data  Area  Length=0034  (52)  Bytes 


Subroutines  Referenced: 

SETTXT  GETPSB  6ETINT 


Variables: 

TXTVAL  0001* 

ONANE  /PR0B/+02B2 
I  OTYPE  /PR0B/+02D2 

NVAR  /PR0B/+02D8 
RHS  /PR0B/+01EA 
INTVAL  002C* 

COMMON  Length 

/PR0B/02E1  (737) 

Labels: 

5L  0000’ 


NAME 

ooo  r 

CNAHE 

/PR0B/+0190 

FNAME 

/PR0B/+02D9 

CTYPE 

/PR0B/+O1E0 

NCON 

/PRQB/+02D6 

NQBJ 

/PR0B/+02D7 

CON 

/PROB'+OOOO 

OBJ 

/PR0B/+0212 

ISTAT 

0029  ‘ 

T: 000002 

0021 

9999L  0049’ 


c*  C*t 


EDTPRB  —  Edit  Problem 

Processing  Description.  EDTPRB  handles  all  problem 
edit  functions  that  are  offered  by  the  PCADA  system.  When 
the  user  indicates  that  he  wants  to  modify  the  current  prob¬ 
lem,  EDTPRB  is  called  by  PCADA.  The  first  task  of  EDTPRB  is 
to  determine  which  editing  function  is  desired.  The  follow¬ 
ing  options  are  available: 


—  Add/delete  objective  function 

—  Add/delete  constraint 

—  Add/delete  variable 

—  Edit  objective  coefficients 

—  Edit  constraint  coefficients 

—  Edit  constraint  right  hand  side 


After  the  user  indicates  which  edit  function  is  desired, 
EDTPRB  prompts  the  user  for  all  information  necessary  to 
make  the  modification.  Following  each  edit  operation,  the 
user  is  given  the  opportunity  to  perform  do  other  edit  oper¬ 
ations.  When  the  user  indicates  that  no  more  modifications 
are  desired,  EDTPRB  calls  SAVPRB  to  save  the  modified  prob¬ 
lem  to  disk.  The  modified  problem  is  saved  using  the 
original  file  name  thus,  the  original  file  is  lost. 

Key  Local  Variables. 

F714  and  F917  —  These  arrays  contain  format  statements  that 
require  subtle  modifications  depending  on  the  prob¬ 
lem.  The  technique  of  using  data  defined  format 
statements  saves  considerable  space  over  the  alter¬ 
native  of  requiring  several  slighty  different  for 
mat  statements. 

Module  Listing.  The  following  pages  contain  the 


FORTRAN  compilation  listing  for  EDTPRB. 


FQRTRAN-80  Ver.  3.43  Copyright  1978-1981  <0  By  Microsoft  --  Bytes:  25131 
Created:  27-Jun-Bl 
1  SUBROUTINE  EDTPRB 


3 

4 

5 

6 

7 

8 

9 

10 
11 
12 

13 

14 

15 

16 
17 
IS 

19 

20 
21 
22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 


C 

C 

C 

C 

C 

C 

C 

C 

C 

C 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 


Subroutine  EDTPRB  —  Edit  Proble* 


This  subroutine  handles  all  EDIT  Functions  applicable  to  current 
problets.  It  is  invoked  by  PCADA  whenever  the  user  specifies  that 
he  wants  to  EDIT  his  problei.  The  user  can  select  froa  here,  one  or 
all  editing  functions  and  when  done  requests  exit.  Nine  editing 
functions  are  handled.  They  are: 

1.  Add  objective  function 

2.  Delete  objective  function 

3.  Add  constraint 

4.  Delete  constraint 

5.  Add  variable 

6.  Delete  variable 

7.  EDIT  objective  coefficients 

8.  EDIT  constraint  coefficients 

9.  EDIT  constraint  right  hand  side 

this  subroutine  has  no  calling  paraseters. . . . 


INTEGER  F914U7) 

INTEGERS  CTYPE(IO),  QTYPEI4),  NCON,  NOBJ,  NVAR 
REAL  CONdO.lOl,  OBJ<4,10),  RHS(IO),  F917114) 

REAL*8  CNAHEUO),  0NAME14),  FN6HE,  NAME 
LOGICAL  TXTVfiL <32) ,  F914XI34),  F917Xi56> 

COMMON  /  PROB  /  CON.  CNAHE,  CTYPE,  RHS,  OBJ,  ONAME,  OTYPE,  NCON, 
1  NOBJ,  NVAR,  FNAME 

EQUIVALENCE  (  TUVALU),  NAME  ),  (  F914I1),  F914XU)  ), 

1  (  F917U),  F917X ( 1 )  ) 


DATA  F914  /  Ml’, 

1  ’AD’, 

DATA  F917  /  M1H  ’ 

1  ’  for’ 

2  ’ FI  1 . ’ 
10  CONTINUE 


H 

DE’,  ’D 


’,1’,  ’9H’,  ’  V’,  ’AR’,  ’ IA’ ,  ’BL’ 


’I-’, 


i 1  i 


’)  ’  / 


’,12,’,  ’28H. ’,  ’  Coe’,  ’ffic’,  ’ient’, 


var 

’5) 


,  Mabl’, 
’  / 


e  x, 


M- 


’H= 


38  C 

39  C  Clear  the  screen  and  write  introductory  aessage 

40  C 

41  WRITE  (  5,  900  ) 

42  12  CONTINUE 

43  CALL  PRSMEN  !  95,  0  ) 

44  C 

45  C  ask  the  user  which  of  the  9  edit  functions  (or  exit!  he  wants  to  do 

46  C 

47 

48 

49 


CALL  GETINT  (  101,  0,  9,  0,  INPRO  ) 

WRITE  (  5,  900  ) 

GO  TO  (  100.  200,  300.  400,  500,  600,  700,  800,  800  ), INPRO 


60  TO  899 
100  CONTINUE 


- process  add  objective  function - 

If  there  are  already  four  objectives,  then  none  can  be  added. 

IF  (  NQBJ  . NE .  4  )  60  TO  110 
WRITE  (  5,  901  ) 

60  TO  12 
110  CONTINUE 
II  =  N03J  +  1 

WRITE  !  5,  902  )  II,  FNAME 

call  to  add  objective  function 

CALL  6ET0BJ  (  II  ) 

60  TO  10 
200  CONTINUE 

- process  delete  objective - 

If  there  is  only  one  objective  left,  you  can’t  delete  it. 

IF  (  NQBJ  .NE.  1)  60  TO  205 
WRITE  (  5,  905  ) 

60  TO  12 
205  CONTINUE 

enter  loop  to  list  the  objective  functions  in  the  current  proble* 

WRITE  (  5,  903  ) 

DO  210  I  =  1,  NOBJ 

WRITE  (  5,  906  )  I,  ONANEII) 

210  CONTINUE 
II  =  NOBJ 

ask  user  which  of  the  objective  functions  he  wants  to  delete. 

CALL  GETINT  (  107,  0.  II,  0.  INTVAL  ) 

IF  (  INTVAL  .EQ,  0  )  80  TO  10 

if  he  wanted  to  delete  the  last  one.  no  proble*.. .otherwise,  *ust 
uppack  the  rest. 

IF  (  INTVAL  .EQ.  NOBJ  )  60  TO  290 

II  =  INTVAL  ♦  1 

DO  220  I  =  II,  NOBJ 

III  =  I  -  1 

ONAME (III)  =  ONAHE(I) 

OTYPE(III)  =  OTYPE(I) 


101  DO  215  J  =  1 .  NVAR 

02  OBJ  < 1 1 1 , J )  =  OBJ(l.J) 

103  215  CONTINUE 

04  220  CONTINUE 

105  290  CONTINUE 

06  C 

07  C  for  successful  deletions,  decreient  the  nunber  of  objective  functions 
108  C 

09  NOB J  =  NOBJ  -  1 

10  60  TO  10 

It  300  CONTINUE 

12  C 

13  C  - process  add  constraint - 

14  C 

15  C  if  there  are  already  10  constraints,  no  aore  can  be  added. 

16  C 

17  IF  (  NCON  ,NE.  10  1  GO  TO  310 

18  WRITE  (  5,  907  1 

19  60  TO  12 

20  310  CONTINUE 

21  II  =  NCON  +  1 

22  WRITE  (  5,  908  )  II,  FNANE 

23  C 

24  C  add  the  constraint 

125  C 

26  CALL  GETCON  (  II  ) 

27  60  TO  10 

28  400  CONTINUE 

29  C 

30  C  - process  delete  constraint - 

31  C 

32  C  if  there  is  only  one  constraint  left,  can’t  delete  it. 

33  C 

34  IF  (  NCON  .NE.  1)  60  TO  405 

35  WRITE  (  5,  911  ) 

36  60  TO  12 

37  405  CONTINUE 

38  C 

39  C  enter  loop  to  list  the  available  constraints  for  the  user 

40  C 

41  WRITE  (  5,  904  ) 

42  DO  410  I  =  1.  NCON 

43  WRITE  (  5,  906  )  I,  CNANE(I) 

44  410  CONTINUE 

45  II  =  NCON 

46  C 

47  C  ask  the  user  which  constraint  he  wants  to  delete. 

48  C 


CALL  6ETINT  (  112,  0,  II,  0,  INTVAL  ) 
IF  (  INTVAL  ,EQ.  0  )  GO  TO  10 


152 

C 

if  he  wants  to  delete  the  last  one  ok.  Otherwise,  the  others 

153 

C 

be  uppacked. 

154 

C 

155 

IF  (  INTVAL  .Efi.  MCON  )  60  TO  490 

156 

II  =  INTVAL  ♦  1 

157 

DO  420  1  =  II,  NOON 

158 

III  =  I  -  1 

159 

CNAHEilll)  =  CNANE(l) 

160 

CTYPEflll)  =  CTYPE(I) 

181 

RHSdlH  =  RHS(I) 

182 

DO  415  J  =  1,  NVAR 

163 

CON(IIIJ)  =  CQN<I,J) 

164 

415  CONTINUE 

165 

420  CONTINUE 

166 

490  CONTINUE 

167 

C 

163 

C 

for  successful  deletions,  decresent  the  nuaber  of  constraints 

169 

C 

170 

NCON  =  NCON  -  1 

171 

GO  TO  10 

172 

500  CONTINUE 

173 

c 

174 

c 

- process  add  variables - 

175 

c 

176 

c 

If  there  are  already  10  variables,  then  no  lore  can  be  added. 

177 

c 

178 

IF  <  NVAR  ,NE.  10  )  GO  TO  505 

179 

WRITE  i  5.  912  1 

180 

80  TO  12 

131 

505  CONTINUE 

192 

c 

183 

c 

increaent  the  variable  counter  and  initialize  all  applicable 

184 

c 

data  to  0.0. 

185 

c 

186 

NVAR  =  NVAR  ♦  1 

187 

DO  510  I  =  1,  NVAR 

188 

CON (I, NVAR)  =  0.0 

189 

510  CONTINUE 

190 

DO  515  I  *  1,  NOBJ 

191 

OBJ (I, NVAR)  =  0.0 

192 

515  CONTINUE 

193 

c 

194 

c 

Infora  user  of  the  nuaber  of  the  variavle  that  was  added,  let  1 

195 

c 

know  that  the  coefficients  have  been  initialized  to  zero. 

196 

c 

197 

F914X (30)  =  X’31’ 

198 

IF  (  NVAR  .EQ.  10  )  F914XI30)  =  X’32’ 

199 

WRITE  (  5,  F914  )  NVAR 

200 

CALL  PRSMEN  !  117.  0  ) 

201 

CALL  6ETTXT  (  122,  0,  32,  0,  TITVAL,  1  ) 

202 

GO  TO  10 

150 


203 

204 

205 

206 

207 

208 

209 

210 
211 
212 

213 

214 

215 

216 

217 

218 

219 

220 
221 
222 

223 

224 

225 

226 

227 

228 

229 

230 

231 

232 

233 

234 

235 

236 

237 

238 

239 

240 

241 

242 

243 

244 

245 

246 

247 

248 

249 

250 

251 

252 

253 


600  CONTINUE 
C 

C  - process  delete  variable - 

C 

C  If  there  is  only  one  variable  left,  it  can  not  be  deleted. 

C 

IF  (  NVAR  ,NE.  1  )  60  TO  605 
WRITE  (  5.  913  ) 

60  TO  12 
605  CONTINUE 
II  =  NVAR 
C 

C  Ask  user  which  variable  he  wants  to  delete 
C 

CALL  6ETINT  (  125,  0,  II.  0.  INTVAL  ) 

IF  (  INTVAL  .EQ.  0  )  60  TO  10 
C 

C  If  he  has  requested  deletion  of  the  last  variable,  fine.  Otherwise 
C  we  sust  uppack  the  regaining  variables. 

C 

IF  (  INTVAL  .EQ.  NVAR  )  60  TO  690 

II  =  INTVAL  +  1 

DO  620  J  =  II,  NVAR 

JJ  =  J  -  1 

DO  610  I  =  1,  NCON 

CON(I.JJ)  =  C0N!I,J) 

610  CONTINUE 

DO  615  1  =  1,  NOBJ 
OBJ (I, JJ)  =  OBJ  (I, J) 

615  CONTINUE 
620  CONTINUE 
690  CONTINUE 
C 

C  Decre*ent  the  nuaber  of  variables. 

C 

NVAR  =  NVAR  -  1 
60  TO  10 
700  CONTINUE 
C 

C  - process  EDIT  objective  coefficients - 

C 

WRITE  (  5.  919  ) 

C 

C  6ive  a  list  of  the  available  objective  functions,  then  ask  the  user 
C  which  one  he  wants  to  EDIT. 

C 

DO  710  I  =  1,  NOBJ 

WRITE  (  5.  906  )  I.  ONAHE(I) 

710  CONTINUE 
II  =  NOBJ 

CALL  GETINT  (  130,  0.  II.  0,  INTVAL  ) 
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IF  (  INTVAL  .ES.  0  I  60  TO  10 
715  CONTINUE 

WRITE  (  5,  919  ) 

WRITE  (  5.  916  )  INTVAL.  GNAHE < INTVAL) 

C 

C  Enter  loop  to  generate  a  *enu  containing  the  current  value  for 
C  each  coefficient  in  the  selected  objective. 

C 

DO  730  1=1,  NVAR 
F917X (42)  =  X ' 3 1  ’ 

IF  1  I  .EQ.  10  )  F917X  <42)  =  X' 32’ 

WRITE  (  5,  F917  )  I,  I.  OBJ (INTVAL, I) 

730  CONTINUE 
II  =  NVAR 
C 

C  Ask  the  user  which  coefficient  to  EDIT. 

C 

CALL  6ETINT  <  135,  0.  II,  0,  INT2  1 
IF  (  INT2  .EQ.  0  )  60  TO  700 
C 

C  Ask  the  user  for  the  net*  coefficient  value. 

C 

CALL  6ETFLT  (  140,  0,  99999.0,  -99999.0,  OBJ (INTVAL. INT2)  ) 

60  TO  715 
800  CONTINUE 
C 

C  - process  EDIT  constraint - 

C  (NOTE:  both  coefficient  and  RHS  edits  begin  here. 

C 

WRITE  (  5.  920  ) 

C 

C  Enter  loop  to  list  the  constraints  in  the  current  problei. 

C 

DO  810  1=1,  NCON 

WRITE  (  5,  906  I  I,  CNANE(I) 

810  CONTINUE 

II  =  143 

IF  (  INPRO  .EQ.  9  )  II  =  148 

III  =  NCON 
C 

C  Ask  the  user  which  co  C 

CALL  6ETINT  (  II,  0,  III,  0.  INTVAL  ) 

IF  (  INTVAL  ,E8.  0  )  GO  TO  10 
81599  WRITE  (  5,  920  ) 

C 

C  At  this  point  RHS  processing  branches. 

C 

IF  <  INPRO  .EQ.  9  )  60  TO  850 
WRITE  (  5,  921  )  INTVAL,  CNAME ( INTVAL) 

C 

C  Enter  loop  to  generate  a  eenu  shotting  each  constraint  coefficient. 


DO  830  1=1,  NVAR 
F917X (42)  =  X ’ 3 1’ 

IF  (  1  ,E9.  10  )  F917X (42)  =  *’32’ 
WRITE  (  5,  F917  )  I,  I.  CON ( INTVAL, I ) 
830  CONTINUE 
II  =  NVAR 


Ask  the  user  which  coefficient  to  change. 

CALL  SETINT  (  135.  0,  II.  0.  INT2  ) 

IF  (  INT2  .E8.  0  )  60  TO  800 

Ask  user  for  lue 

CALL  8ETFLT  (  140,  0,  99999.0,  -99999.0,  CON ( INTVAL. INT2)  ) 

60  TO  815 
850  CONTINUE 

Show  user  the  current  right  hand  side  value  (RHS) 

WRITE*  5,  923TVAL,  RHS (INTVAL) 

Ask  user  for  a  new  right  hand  side  value. 

CALL  GETFLT  (  154,  0.  99999.0,  0.0.  RHS (INTVAL)  ) 

60  TO  800 

899  CONTINUE 

Save  the  aodified  problea  to  disk. 

CALL  SAVPRB  (  ISTAT  ) 

900  FORMAT  (  1H1  ) 

901  FORMATLREADY  HAS  THE  NAXIHUH  OF  4 

1  ’OBJECTIVE  FUNCTIONS  »**’,/) 

902  FORMAT  (  1H  ,’AODING  OBJECTIVE’, 12,’  TO  PROBLEM  ',A8./> 

903  FORMAT  (  1H  ,  ’DELETE  OBJECTIVE’,  /  ) 

904  FORMAT  (  1H  ,  ’DELETE  CONSTRAINT’,  /  ) 

905  FORMAT  (  1H  ,’mt  YOUR  PROBLEM  CURRENTLY  HAS  THE  MINIMUM  ’, 

1  ’ALLOWABLE  1  OBJECTIVE  ♦*♦♦',/) 

904  FORMAT  (  1H  ,’  ’,12,’.  ’,A8) 

907  FORMAT  (  1H  ,’***♦  YOUR  PROBLEM  ALREADY  HAS  THE  MAXIMUM  OF  10 

1  ’  CONSTRAINTS  *♦**’,/) 

908  FORMAT  (  1H  , ’ADDING  CONSTRAINT’, 12,’  TO  PROBLEM  ’,A8,/> 

911  FORMAT  (  1H  ,’**»♦  YOUR  PROBLEM  CURRENTLY  HAS  THE  MINIMUM  ’, 

1  ’ALLOWABLE  1  CONSTRAINT  *♦*»’,/) 

912  FORMAT  (  1H  ,’»**♦  YOUR  PROBLEM  ALREADY  HAS  THE  MAXIMUM  OF  10 

1  ’  VARIABLES  **♦♦’,/) 

913  FORMAT  (  1H  .’♦♦#♦  YOUR  PROBLEM  ALREADY  HAS  THE  MINIMUM  OF  1’ 

1  ’  VARIABLE  »♦«*’,/) 

914  FORMAT  (  1H  /Following  are  the  objective  coefficients  for  ’, 
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359  919  FORMAT  (  lHl.’EDIT  OBJECTIVE  FUNCTION’,/) 

360  920  FORMAT  (  1H1, ’EDIT  CONSTRAINT’,/) 

361  921  FORMAT  (  48H  Following  are  the  coefficients  for  constraint 

362  1  12,  2H:  ,  A8,  /  ) 

363  923  FORMAT  (  37H  The  right  hand  side  for  constraint,  12,  4H  is 

364  1  FI  1.5,  /  > 

365  RETURN 

366  END 

Proara*  Unit  Length=0A2F  (2607)  Bytes 
Data  Area  Length=0480  (1152)  Bytes 

Subroutines  Referenced: 


$13 

$12 

$11 

$10 

$N2 

$ND 

PRSMEN 

GETINT 

$C8 

GETOBJ 

$L3 

$T3 

$L1 

$T1 

GETCON 

$M9 

SAVPRB 

GETTXT 

GETFLT 

Variables! 

F9i4  ooor 

CTVPE 

/PR0B/+01E0 

OTYPE 

/PR0B/+02D2 

NCON  /PR0S/+02D6 

NDBJ 

/PR08/+O2D7 

NVAR 

/PROB/+02D8 

CON  /PR08/+0000 

OBJ 

/PR0B/+0212 

RHS 

/PR0B./+01EA 

F917  0023' 

CNAME 

/PRQB/+0190 

ONAME 

/PRDB/+02B2 

FRAME  /PR0B/+02D9 

NAME 

005B" 

TXTVAL 

005B" 

F914K  0001 1 

F917X 

0023* 

INPRO 

007B" 

T;  000002 

0083' 

II 

0034“ 

I 

00B6’ 

T: oooooo 

0088“ 

INTVAL 

008A" 

III 

0092" 

t: oioooo 

0094" 

J 

0096" 

T: 020000  0098 

T 1030000 

009A" 

JJ 

0080“ 

INT2 

00B8‘ 

ISTAT  CODE’ 
COMMON  Length 


/PR0B/02E1  (737) 


020D* 

908L 

025B- 

4051 

0282’ 

02SD* 

90  4  L 

0185’ 

410L 

02C4’ 

03F0' 

420L 

03DC’ 

415L 

03C8’ 

0413’ 

9121 

02E2" 

510L 

0453’ 

0498’ 

9161 

0511’ 

913L 

032 E“ 

0622’ 

6201 

060E  ’ 

610L 

05AC’ 

05FA’ 

919L 

03C8" 

7101 

066E’ 

06A8’ 

9161 

0378" 

730L 

074F’ 

03E9" 

8101 

07FE’ 

81 5L 

085E’ 

098C’ 

9211 

0402 " 

830L 

091C’ 

0444 
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GETANS 


Get  Answer 


Processing  Description.  GETANS  is  called  by  the  input 
processors  (GETINT,  GETFLT,  and  GETTXT)  to  obtain  the  next 
input  item  from  the  user.  GETANS  will  obtain  the  input  item 
from  the  previously  read  input  record  if  it  contains  unpro¬ 
cessed  data,  if  not,  it  will  read  a  new  input  record  from 
the  standard  input  device  (logical  unit  #5).  Before  exam¬ 
ining  the  input,  GETANS  converts  all  lower  case  inputs  to 
upper  case.  At  this  point,  GETANS  scans  the  input  record 
for  the  next  input  item.  A  description  of  syntax  rules  used 
by  GETANS  appears  in  the  program  listing. 

In  addition  to  locating  the  input  item,  GETANS  classi¬ 
fies  the  item  as  to  type  (i.e.,  integer,  floating  point,  or 
text).  GETANS  also  examines  all  inputs  to  determine  if  the 
user  has  requested  HELP  or  if  he  has  requested  a  display  of 
the  current  problem.  HELP  is  indicated  if  the  user  enters 
"HELP"  or  and  a  problem  display  is  indicated  if  the 

user  enters  or  "@P".  If  one  of  these  conditions  is 

detected,  GETANS  will  set  the  calling  parameter  IHELP  to  1 
(for  HELP)  or  2  (for  display). 

Key  Local  Variables. 

IPNT  —  This  item  is  used  as  a  counter  of  the  number  of 
characters  in  the  input  item  currently  being 
processed . 

Module  Listing.  The  following  pages  contain  the 
FORTRAN  compilation  listing  for  GETANS. 
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FORTRAN-80  Ver.  3.43  Copyright  1978-1981  !C)  By  Microsoft  --  Bytes!  25131 
Created:  27-Jun-Sl 

1  SUBROUTINE  SETflNS  (  INDATA,  ITYPE,  1NTVAL,  FPVAL,  TXTVAL,  ILEN, 

2  1  II,  IHELP  ) 

3  C 

4  C  Subroutine  SETANS  --  Set  Answer 

5  C 

6  C  This  subroutine  is  called  to  obtain  a  value  froa  the  input  strea*. 

7  C  It  can  either  be  called  to  read  a  new  card  isage,  or  to  process 

8  C  data  fro*  the  previously  read  card  iiage.  6ETANS  saintains  a 

9  C  pointer  to  the  sost  recently  read  card  isage.  SETANS  classifies 

10  C  all  inputs  into  one  of  three  types!  INTEGER,  FLOAT IN6  POINT  or  TEXT. 

11  C  All  digits  is  INTEGER,  all  digits  with  one  decisal  point  is 

12  C  FLOATING  POINT,  and  everything  else  is  TEXT.  For  INTE6ER  and 

13  C  FL0ATIN6  POINT,  a  leading  plus  (+!  or  sinus  (-)  sign  is  allowed. 

14  C  Several  syntax  rules  apply!  a)  each  value  sust  be  less  than  32 

15  C  characters  in  length,  after  32  characters,  an  ’invisible’  deliainter 

IS  C  is  assumed,  b)  coaaas  and/or  blanks  serve  as  deliaiters,  and  all 

17  C  other  special  characters  are  legal  text  data,  c)  the  input  record 
13  C  is  liaited  to  129  characters,  d)  leading  blanks  are  ignored,  e) 

19  C  INTEGERS  sust  be  in  the  range  -32767  to  +32767,  larger  integer 

20  C  values  are  converted  to  floating  point,  but  are  =  0  as  integers. 

21  C  f)  FLOATING  POINT  values  aust  be  15  digits  or  less. 

22  C 

23  C  Paraaeter  descriptions 

24  C 

25  C  INDATA  —  logical  array  tG  contain  the  input  record 

26  C  ITYPE  --  returned  to  calling  prograa,  identifying  input  type 

*3T  r  *  -  Mirrrrn 

a./  u  1  “  llllLUtn 

28  C  2  =  FLOATING  POINT 

29  C  3  =  TEXT 

30  C  4  =  illegal  INTEGER  lie  >  32767  ) 

31  C  5  =  illegal  FLOATING  POINT  (ie  >  15  digits  ) 

32  C  INTVAL  --  the  integer  value  of  the  input,  if  applicable 

33  C  FPVAL  —  the  floating  point  value  of  the  input,  if  applicable 

34  C  TXTVAL  —  the  text  value  of  the  input 

35  C  ILEN  --  the  length  of  the  input  (characters) 

36  C  II  --  pointer  to  INDATA,  if  =  1  then  GETANS  will  read  a  new 

37  C  record 

38  C  IHELP  --  indicates  that  the  user  has  requested  help 

39  C 

40  LOGICAL  TXTVAL (32),  INDATA ( 128) ,  TEilP(S) 

41  INTEGER+1  CTYPE(IO),  GTYPE <4> ,  NCON,  NOBJ,  NVAR 

42  REAL  CON (10,10),  08J(4,10),  RHS(IO) 

43  REAL+3  CNAME(IO),  QNAHE(4),  F NAME 

44  COMMON  /  PR0B  /  CON.  CNAME,  CTVpE,  RHS.  OBJ.  0NAME.  GTYPE,  NCON. 

45  1  NOBJ.  NVAR,  FNAME 

46  EQUIVALENCE  (  FNAME.  TEMPI  1)  ! 

47  C 

48  C  Check  to  see  if  a  new  input  record  should  be  reap, 

49  C 
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50  10  CONTINUE 

51  IF  !  I!  .HE.  1  >  60  TO  50 

52  WRITE  I  5,  1002  ) 

53  READ (5,1 000, ERR=50)  < INDATA < I ) , 1=1 , 1 28) 

54  50  CONTINUE 

55  C 

56  C  initialize  variables 

57  C 

53  FP'VAL  =  0.0 

59  I HELP  =  0 

60  INTVAL  =  0 

61  ILEN  =  0 

62  ITYPE  =  1 

63  IP NT  =  1 

64  C 

65  C  check  to  see  it  the  end  of  the  current  input  record  has  been 

66  C  reached,  if  so,  return  defaults  as  input. 

67  C 

63  IF  (  II  .ST.  128  )  60  TO  250 

69  C 

70  C  enter  loop  to  isolate  the  nest  value  on  the  input  record. 

71  C 

72  DO  200  I  =  II.  123 

73  C 

74  C  Upshift  lowercase  inputs 

75  C 

76  IF  !  INDATA ( I )  .6E.  97  .AND.  INDATA < I )  .LE.  122  ) 

77  1  INDATA(I)  =  INOATA(I)  -  32 

78  III  =  I  +  1 

79  C 

80  C  Look  for  leading  blanks 

81  C 

82  IF  (  INDATA(I)  ,E8.  X’20’  .AND.  IPNT  .ES.  1  )  60  TO  200 

83  C 

84  C  Check  for  conaa  or  blank  (indicates  nest  array  eleaent) 

85  C 

86  IF  (  IHDATA(I)  .ES.  F2C’  .OR.  INDATA(I)  .ES.  1*20’  )  GO  TO  210 

87  C 

88  C  Check  for  period  (.)  indicates  floating  point  value 

89  C 

90  IF  (  INDATA  (I  )  .ES.  F2E’  )  SO  TO  180 

91  C 

92  C  Check  for  leadino  sinus  sign  (-)  indicating  negative  value 

93  C 

94  IF  (  INDATA  (I)  .ES.  X’2D’  .AND.  IPNT  .ES.  1  )  GO  TO  198 

95  C 

96  C  Check  for  a  digit  (0, 1,2,3.4,5.6,7,8,91 

97  C 

98  IF  (  INDATA  (I)  .LT.  X’30’  ,0R. 

99  1  INDATA ( I )  .GT.  X’39’  )  ITYPE  =  3 

100  60  TO  198 
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101  180  CONTINUE 

102  C 

103  C  incretent  type  count.  If  type  *45  an  integer,  then  finding  a 

104  C  deriaal  point  proaotes  it  to  floating,  if  it  *as  already 

105  C  floating,  then  finding  another  deciaal  proaotes  it  to  text. 

106  C 

107  IF  (  ITVPE  .IT.  3  )  I  TYPE  =  I TYPE  +  1 

108  198  CONTINUE 

109  C 

110  C  save  the  next  character  and  incresent  the  count 

111  C 

112  TXTVALUPNT)  =  INDATA(I) 

113  IPNT  =  IPNT  +  1 

114  C 

115  C  if  current  value  is  33  then  assuae  deiiaiter  and  cut  off  the  value 

116  C 

117  IF  (  IPNT  ,E9.  33  )  SO  TO  210 

113  200  CONTINUE 

119  210  CONTINUE 

120  C 

121  C  prepare  for  nuafaer  conversion,  if  type  found  was  text,  then 

122  C  conversion  does  not  apply. 

123  C 

124  IF  (  I  TYPE  .Efi.  3  >  GO  TO  240 

125  C 

126  C  check  for  a  value  that  can  not  be  converted  lie,  greater  than 

127  C  15  characters) 

123  C 

129  IF  !  IPNT  .LE.  15  )  SO  TO  215 

130  1TYPE  =  ITYPE  +  3 

131  60  TO  250 

132  215  CONTINUE 

133  C 

134  C  store  trailing  blanks  in  the  array  that  is  about  to  be  decoded 

135  C  as  floating  point. 

136  C 

137  DO  217  I  =  IPNT.  15 

138  TXTVAL ! I )  =  X’20' 

139  217  CONTINUE 

140  C 

141  C  if  value  found  was  an  integer,  add  a  deciaal  point  for  the 

142  C  conversion  routine, 

143  C 

144  IF  (  ITYPE  ,E9.  1  )  TXTVALUPNT!  =  X’2E’ 

145  DECODE  !  TXTVAL, 1001  )  FPVAL 

146  TXTVAL ( IPMT)  =  X’20’ 

147  C 

148  C  see  if  floating  point  value  exceeds  the  capacity  of  an  integer 

149  C  variable 

150  C 

151  IF  !  ABS (FPVAL )  .ST.  32767.0  )  SO  TO  220 
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152 

INTVAL  =  FPVAL 

153 

60  TO  250 

154 

220  CONTINUE 

155 

C 

156 

C  set  type  to  indicate  illegal  integer  Has  found 

157 

C 

158 

IF  (  I TYPE  .EQ.  1  )  [TYPE  =  4 

159 

240  CONTINUE 

160 

C 

161 

C  Check  to  see  if  the  text  input  is  a  request 

for  HELP 

162 

C 

163 

IF  (  IPNT  .EQ.  5  .AND. 

164 

1  mVAL(l)  .EQ.  *’18'  .AND. 

165 

2  TXTVAL (2)  .EQ.  X’45’  .AND. 

166 

3  TXTVAL (3)  .EQ.  F4C’  .AND. 

167 

4  TXTVAL (4)  .EQ.  X'50’  )  I HELP  =  1 

168 

IF  (  IPNT  .EQ.  2  .AND.  TUVALU) 

.EO.  r 

3F'  )  IHELP  = 

169 

IF  (  TEMPI  1)  .EQ.  X’2F!  )  60  TO  250 

170 

IF  (  IPNT  .EQ.  2  .AND.  TUVALU! 

.EQ.  X ’ 40 ’  )  IHELP  = 

171 

IF  (  IPNT  .EQ.  3  .AND.  TUVALU) 

.EQ.  X' 40’  .AND. 

172 

1  TXTVAL <2>  .EQ.  X’50’  )  IHELP 

=  3 

173 

250  CONTINUE 

174 

C 

175 

C  set  ite*  length,  and  save  the  current  input  pointer. 

176 

C 

177 

ILEN  =  IPNT  -  1 

178 

11  =  III 

179 

1000  FORMAT ( 128A1 ) 

180 

1001  FORMAT (F15.5) 

181 

1002  FORMAT  (  1H  ) 

182 

RETURN 

183 

END 

Prograa  Unit  Length=0483  (1203)  Bytes 

Data  Area  Length=0040  (64)  Bytes 

Subroutines  Referenced: 

$12 

$11 

ABS 

$AT 

$W2 

$ND 

$R5 

$L1 

$71 

$QD 

$SB 

$CH 

Variables! 

INDATA 

0001 ‘  ITYPE  0003" 

INTVAL 

0005" 

FPVAL 

0007*  TXTVAL  0009“ 

ILEN 

OOOB" 

II 

GOOD"  [HELP  OOOF ' 

TEMP 

/PR0B/+02B9 

CTYPE 

/PRQB/+01E0  OTYPE  /PROB/+02D2 

NCON 

/PROB/+02D6 

NOS  J 

/PR0B/+02D7  NVAR  /PR0B/+02D8 

CON 

/PROB/ i-OOOO 

OBJ 

/PR0B/+0212  RHS  /PR0B/+01EA 

CNfiME 

/PR0B./+0190 

ONAME  /PR0B/+02B2 

FNAME 

/PR08/+02D9 

t:  000002 

I  0018' 

T: oooooo 

001A* 

1PNT  001C 

T: 010002 

00  IE" 

Hi 

001F“ 

T: oioooo 

T: 020002 

0023* 

T : 030002 

0024* 

1:040002 

COMMON  Length 


/PR0B/02E1  (737) 


6ETCQN  —  Get  Constraint 

Processing  Description.  GETCON  is  called  by  both 
EDTPRB  and  NEWPRB  whenever  a  problem  constraint  is  to  be 
entered.  GETCON  prompts  the  user  for  all  constraint  infor¬ 
mation  including,  constraint  name,  constraint  coefficients, 
constraint  type  (i.e.,  greater  than,  equal,  or  less  than), 
and  constraint  right  hand  side  value.  The  constraint  is 
added  to  the  problem  as  constraint  number  NOON  +  1. 

The  first  question  GETCON  asks  the  user  is  for  the 
constraint  name.  If  the  user  is  done  entering  constraints 
(when  first  defining  the  problem)  or  no  longer  wishes  to  add 
a  constraint  (when  editing  the  problem),  he  indicates  this 
to  PCADA  by  responding  “/"  when  asked  for  the  constraint 
name.  If  no  constraint  is  added,  GETCON  sets  its  calling 
parameter  (II)  to  — 1.  Upon  entry  to  GETCON,  II  is  set  to 
the  desired  constraint  number 

Key  Local  Variables.  Refer  to  the  module  listing. 
Module  Listing.  The  following  pages  contain  the 
FORTRAN  compilation  listing  for  GETCON. 

Jl 

« 
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FORTRAN-30  Ver.  3.43  Copyright  1978-1981  (C!  By  Microsoft  --  Bytes:  25131 
Created:  27-Jun-81 

1  SUBROUTINE  6ETCQN  (  II  ) 

2  C 

3  C  Subroutine  SETCQN  --  Bet  Constraint 

4  C 

5  C  This  subroutine  is  called  to  prcspt  the  user  for  the  inforaation 

6  C  needed  for  a  constraint.  It  is  assused  that  the  constraint  being 

7  C  added  is  the  currently  last  constraint,  so  NCON  is  adjusted 

8  C  accordingly.  Control  is  returned  when  all  constraint  data  has 

9  C  been  obtained  or  when  the  user  says  he  doesn’t  want  to  define  a 

10  C  constraint. 

11  C 

12  C  paraaeter  description  -- 

13  C 

14  C  II  --  is  input  as  the  constraint  nusber.  It  is  unchanged  unless 

15  C  the  user  decides  against  entering  the  constraint  in  which  case 

14  C  it  is  set  to  -1. 

17  C 

18  L06ICAL  TXTVAL (32) ,  F905X(56) 

19  INTEGERS  CTYPEUO),  0TYPE(4>,  NCON,  NQBJ ,  NVAR 

20  REAL  CON (10, 10) .  Q8J<4,10),  RHS(IO),  F905U4) 

21  REAL *8  NAME,  FNAME,  CNAME(IO),  ONAME (4) 

22  COMMON  /  PROB  /  CON,  CNAME,  CTYPE,  RHS,  OBJ.  ONAME.  OTYPE,  NCON, 

23  1  NQBJ,  NVAR,  FNAME 

24  EQUIVALENCE  (  TXTVAL <  1 ) ,  NAME  ),  1  F905U),  F905X11)  ) 

25  DATA  F905  /  M44H’,  ’  Ent’,  ’er  c\  ’onst’,  ’rain’,  ’t  co’, 

24  1  ’effi’,  ’cien’,  ’t  fo’,  ’r  va’,  ’riab’,  ’ le  *’, 

27  2  ’.I-,’,  ’/)  ’  7 

28  C 

29  C  ask  for  the  constraint  naae  (optional) 

30  C 

31  CALL  8ETTXT  (  79.  0,  8,  0,  TXTVAL.  1  ) 

32  C 

33  C  if  the  naae  is  then  the  user  is  done  inputting  constraints. 

34  C 

35  IF  (  TXTVAL (1)  .NE.  X’2F’  )  60  TO  30 

34  II  =  -1 

37  GO  TO  9999 

38  30  CONTINUE 

39  C 

40  C  save  the  nusber  of  constraints  and  the  constraint  naae. 

41  C 

42  NCON  =  II 

43  CNAME (II)  =  NAME 

44  C 

45  C  enter  loop  on  the  nuaber  of  variables  to  define  the  coefficients  for 

44  C  this  constraint. 

47  C 

48  DO  110  J  =  1,  NVAR 

49  F905XI51)  =  X’3P 


IF  (  J  .£8.  10  )  F905X (51 )  =  X’32’ 
WRITE  1  5,  F905  )  J 


50 

51 

52  C 

53  C  get  the  constraint  coefficient 

54  C 

55  CALL  SETFLT  (  84,  1,  99999.0,  -99999.0.  C0H4II.J)  ) 

56  110  CONTINUE 

57  C 

58  C  call  6ETINT  to  ask  the  user  what  relation  applies  to  this  constraint 

59  C  1  -->  less  than  or  equal 

60  C  2  -->  equal 

61  C  3  -->  greater  than  or  equal 

62  C 

63  CALL  SET I NT  (  87,  0,  3,  1,  1NTVAL  > 

64  CTYPEIII)  =  INTVAL 

65  C 

66  C  call  SETFLT  to  get  the  right  hand  side  for  the  constraint.  Note. 

67  C  negative  right  hand  sides  are  not  allowed. 

68  C 

69  CALL  SETFLT  (  160.  0,  99999.0.  0.0.  RHS(II)  ) 

70  9999  CONTINUE 

71  RETURN 

72  END 


Prograa  Unit  Length=0149  (329)  Bytes 
Data  Area  Length=007E  (126)  Bytes 

Subroutines  Referenced: 


$10 

6ETTXT 

$L3 

$T3 

m 

$ND 

6ETFLT 

$M9 

6ETINT 

Variables: 

11 

0001  ■ 

TXTVAL 

0003* 

F905X 

0023* 

CTYPE 

/PR0B/+01E0 

OTYPE 

/PR0B/+02D2 

NCON 

/PR0B/+02D6 

N08J 

/PR0B/+02D7 

NVAR 

/PRQ8/+02D8 

CON 

/PRDB/+0000 

OBJ 

/PR0B/+0212 

RHS 

/PR0B/+01EA 

F905 

0023" 

NAME 

0003* 

FNAME 

/PR0B/+02D9 

CNAME 

/PR0B/+0I90 

0NAME 

/PRQB/+02B2 

t: ooooo; 

!  0063* 

T:  000000  0064' 

J 

0066* 

T: oioooo 

i  0068* 

INTVAL 

0070* 

COMMON  Length 
/PR0B/02E1  (737) 


Labels: 

30L  002B’  9999L  0118’  110L  00C1 ’ 
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GETFLT 


Get  Floating  Point 


Processing  Description.  GETFLT  is  one  of  the  PCADA 
input  processors.  It  is  designed  to  present  a  question  and 
obtain  a  floating  point  value  in  response.  GETFLT  will  not 
return  control  to  the  calling  program  until  it  obtains  a 
legal  floating  point  value  within  the  specified  range.  For 
each  call  to  GETFLT,  the  user  specifies  the  acceptable  value 
range  with  the  calling  parameters.  FHIGH  indicates  the 
highest  acceptable  value  and  FLOW  indicates  the  lowest 
acceptable  value.  Illegal  inputs  (i.e.,  text  or  erroneous 
numerics)  and  out  of  range  values  will  cause  GETFLT  to 
generate  an  appropriate  error  message.  GETFLT  will  alst 
call  PROHLP  when  needed  in  response  to  user  HELP  or  display 
problem  requests.  After  a  HELP,  a  display  request,  or  an 
error  message,  GETFLT  will  reask  the  question  and  look  for  a 
legitimate  floating  point  response.  The  process  is 
continued  until  a  legal  floating  point  value  is  obtained. 

Key  Local  Variables.  Refer  to  the  module  listing. 

Module  Listing.  The  following  pages  contain  the 

FORTRAN  compilation  listing  for  GETFLT. 
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FORTRAN-80  Ver,  3.43  Copyright  1978-1981  10  By  Microsoft  --  Bytes:  25131 
Created:  27-Jun-Bl 

1  SUBROUTINE  SETFLT  1  MENUID.  HENBEN,  FHI6H,  FLOS.  FPVAL  ) 

2  C 

3  C  Subroutine  SETFLT  --  Bet  Floating  Point 

4  C 

5  C  Subroutine  SETFLT  is  called  whenever  a  floating  point  input  is  to 

6  C  be  obtained  froa  the  user.  This  subroutine  will  not  return  control 

7  C  to  the  calling  prograa  until  a  legal  floating  point  value  within 

8  C  the  specified  range  has  been  obtained.  Erroneous  inputs  result  in 

9  C  the  generation  of  an  appropriate  error  aessage  and  the  regeneration 

10  C  of  the  aenu  or  question.  If  the  user  should  input  "?“  or  'help1, 

11  C  SETFLT  will  call  PRSHEN  to  disply  that  question’s  help  inforsation. 

12  C 

13  C  parameter  descriptions: 

14  C 

15  C  MENUID  --  Contains  the  identification  of  the  desired  aenu. 

16  C  HENBEN  —  Specifies  whether  or  not  the  aenu  is  to  be  displayed.  In 

17  C  soae  cases,  the  calling  prograa  »ay  have  generated  a 

18  C  variable  aenu,  and  just  desire  the  answer.  Setting 

19  C  HENBEN  to  a  nonzero  value  will  suppress  the  generation 

20  C  of  the  aenu. 

21  C  FHIGH  --  This  itea  contains  the  highest  floating  point  value  that 

22  C  is  acceptable  for  this  input. 

23  C  FLOW  --  This  itea  contains  the  lowest  floating  point  value  that  is 

24  C  acceptable  for  this  input. 

25  C  FPVAL  --  This  itea  is  returned  to  the  calling  prograa  containing 

26  C  the  users  input  floating  point  value. 

27  C 

28  LOGICAL  TXTVfiL(32),  INDATA (128) 

29  10  CONTINUE 

30  C 

31  C  Deteraine  if  the  aenu  should  be  displayed  for  this  request.  If  so, 

32  C  call  PRSMEN  to  present  it. 

33  C 

34  IF  (  MEN6EN  .NE.  0  )  BO  TO  20 

35  CALL  PRSMEN  (  MENUID,  0  ) 

36  20  CONTINUE 

37  C 

38  C  Set  the  input  record  pointer  (II)  to  indicate  that  a  new  input 

39  C  record  should  be  read,  and  then  call  SETANS  to  get  a  response 

40  C  froa  the  user, 

41  C 

42  II  =  1 

43  CALL  SETANS  (  INDATA,  ITYPE,  INTVAL,  FPVAL,  TXTVAL,  ILEN, 

44  1  II,  I HELP  ) 

45  C 

46  C  Deteraine  if  the  user  requested  help,  and  if  he  did,  call  PRSMEN 

47  C  to  generate  the  help  display  for  this  aenu. 

48  C 

44 


IF  (  IHELP  ,E9.  0  )  GO  TO  30 


50  CALL  PROHLP  (  1HELP,  MENU ID  ) 

51  80  TO  10 

52  30  CONTINUE 

53  C 

54  C  Check  for  an  illegal  floating  point  input  value  lie  floating  point 

55  C  inputs  *ust  be  less  than  15  characters  in  length  --  including  the 

56  C  sign  and  deciaal  point). 

57  C 

53  IF  (  ITYPE  .LE.  3  .OR.  I  ITYPE  .EB.  4  .AND.  ILEN  .LE.  15  )  ) 

59  1  60  TO  50 

60  WRITE  (  5,  900  )  !  TXTVAL(I),  1  =  1.  ILEN  ) 

61  WRITE  (  5,  901  ) 

62  SO  TO  10 

63  50  CONTINUE 

64  C 

65  C  Check  to  see  if  a  text  (ie.  non-floating  point)  value  was  input. 

66  C 

67  IF  (  ITYPE  ,NE.  3  )  60  TO  100 

68  WRITE  I  5,  900  )  !  TXTVAL(I),  1=1,  ILEN  ) 

69  WRITE  (  5,  902  ) 

70  60  TO  10 

71  100  CONTINUE 

72  C 

73  C  Check  to  insure  that  the  floating  point  value  that  was  input  is 

74  C  within  the  desired  range. 

75  C 

76  IF  (  FPVAL  .LE.  FHI6H  .AND.  FPVAL  .SE.  FLOW  )  60  TO  9999 

77  WRITE  1  5  ,  900  >  1  TXTVALU),  1  =  1,  ILEN  ) 

78  WRITE  l  5,  903  )  FLOW,  FHI6H 

79  60  TO  10 

80  900  FORMAT  <  1H  ,’**«  INPUT  ERROR  **«  INPUT  VALUE  =  ’, 

81  1  32A1  ) 

82  901  FORMAT  (  1H  , ’LEGAL  FLOATING  POINT  VALUES  MUST  BE  15  CHARACTERS’ 

83  1  ’OR  LESS.  PLEASE  TRY  AGAIN’,/) 

84  902  FORMAT  <  1H  ,’A  FLOATING  POINT  (OR  INTEGER)  INPUT  IS  REQUIRED’, 

85  1  ’,  PLEASE  TRY  AGAIN',/) 

86  903  FORMAT  !  1H  ,’A  FLOATING  POINT  VALUE  BETWEEN  ’.F15.5,’  AND 

87  1  F15.5, ’  IS  REQUIRED.’,/) 

88  9999  CONTINUE 

89  RETURN 

90  END 

Prograa  Unit  Length=01E3  (483)  Bytes 
Data  Area  Length=01F0  (496)  Bytes 


Subroutines  Referenced: 


input  processors 


It  is  designed  to  present  a  question  and 


obtain  a  integer  value  in  response.  GETINT  will  not  return 
control  to  the  calling  program  until  it  obtains  a  legal 
integer  value  within  the  specified  range.  For  each  call  to 
GETINT,  the  user  specifies  the  acceptable  value  range  with 
the  calling  parameters.  IHIGH  indicates  the  highest  accept¬ 
able  value  and  ILOW  indicates  the  lowest  acceptable  value. 
Illegal  inputs  <i.e.,  text  or  erroneous  numerics)  and  out  of 
range  values  will  cause  GETINT  to  generate  an  appropriate 
error  message.  GETINT  will  also  call  PROHLP  when  needed  in 
response  to  user  HELP  or  display  problem  requests.  After  a 
HELP,  a  display  request,  or  an  error  message,  GETINT  will 
reask  the  question  and  look  for  a  legitimate  integer 
response.  The  process  is  continued  until  a  legal  integer 
value  is  obtained. 

Key  Local  Variables.  Refer  to  the  module  listing. 

Module  Listing.  The  following  pages  contain  the 
FORTRAN  compilation  listing  for  GETINT. 


FORTRAN— 80  Ver.  3.43  Copyright  1978-1981  (0  By  Microsoft  -  Bytes:  25131 


Created: 

1 

2  C 

3  C 

4  C 

5  C 

4  C 

7  C 

8  C 

9  C 

10  c 

11  c 

12  C 

13  C 

14  C 

15  C 

14  C 

17  C 

15  C 

19  C 

20  C 

21  C 

22  C 

23  C 

24  C 

25  C 

24  C 

27  C 

28 

29 

30  C 

31  C 

32  C 

33  C 

34 

35 
34 

37  C 

38  C 

39  C 

40  C 

41  C 

42 

43 

44 

45  C 

46  C 

47  C 

48  C 

49 


27--Jun-81 

SUBROUTINE  SETINT  !  flENUID,  HENGEN.  IHIGH,  ILOW.  IMTVAL  ) 
Subroutine  GETINT  --  Set  Integer 

Subroutine  SETINT  is  called  whenever  an  integer  input  is  to  be 
obtained  froa  the  user.  This  subroutine  will  not  return  control 
to  the  calling  prograa  until  a  legal  integer  within  the  specified 
range  has  been  obtained.  Erroneous  inputs  result  in  the  generation 
of  an  appropriate  error  aessage  and  regeneration  of  the  aenu  or 
question.  If  the  user  should  input  "O'  or  ■HELP1,  GETINT  will 
call  PRSHEN  to  display  that  questions  help  inforaation. 

paraaeter  descriptions: 

HENUID  —  Contains  the  identification  of  the  desired  aenu. 

HENGEN  --  Specifies  whether  or  not  the  aenu  is  to  be  displayed.  In 
soae  cases,  the  calling  prograa  aav  have  generated  a 
variable  aenu,  and  just  desire  the  answer.  Setting 
HENGEN  to  a  nonzero  value  will  suppress  the  generation 
of  the  aenu. 

IHIGH  —  This  item  contains  the  highest  integer  value  that  is 
acceptable  for  this  input. 

ILCW  —  This  itea  contains  the  lowest  integer  value  that  is 
acceptable  for  this  input. 

IMTVAL  —  This  ite#  is  returned  to  the  calling  prograa  containing 
the  users  input  integer  value. 

LOGICAL  TXTVAL (32) ,  INDATAU28) 

10  CONTINUE 

Deteraine  if  the  aenu  should  be  displayed  for  this  request. 

And.  if  so,  call  PRSHEN  to  present  it. 

IF  (  HENGEN  .NE.  0  )  GO  TO  20 
CALL  PRSHEN  (  HENUID,  0  ) 

20  CONTINUE 

Set  the  input  record  pointer  (I!)  to  indicate  that  a  new  input 
record  should  be  read,  and  then  call  GETANS  to  get  a  response 
froa  the  user. 


II  =  1 

CALL  GETANS  (  INDATA,  ITYPE,  INTVAL,  FPVAL .  TXTVAL.  ILEN. 

1  II,  I  HELP  ) 

Deteraine  if  the  user  requested  he] o .  and  if  he  did.  call  PRSHEN 
to  generate  the  help  displav  for  this  aenu. 

IF  I  IHELP  . EQ,  0  )  SO  TO  30 
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W  V 


n"  u*  j  ■  u"  i 


V  w  J 


50 

CALL  PROHLP  (  IHELP,  MENU ID  ) 

51 

GO  TO  10 

52 

30  CONTINUE 

53 

C 

54 

C 

If  an  integer  was  input,  but  it  was  out  of  legal  range,  go  generate 

55 

C 

the  out  of  range  error  aessage. 

56 

C 

57 

IF  (  I TYPE  .E3.  4  )  SO  TO  150 

53 

C 

59 

C 

Check  to  deteraine  if  a  legal  integer  was  input. 

60 

c 

61 

IF  (  I TYPE  .EQ.  1  )  60  TO  100 

62 

c 

63 

c 

For  non-integer  inputs,  generate  the  appropriate  error  aessage. 

64 

c 

65 

WRIIE  (  5,  900  )  (  TXTVftL(I),  I  =  1,  ILEN  ) 

66 

WRITE  (  5,  901  I 

67 

GO  TO  10 

63 

100  CONTINUE 

69 

c 

70 

c 

Check  the  integer  value  to  sake  sure  it  is  within  the  reouested 

71 

c 

range. 

72 

c 

73 

IF  (  INTVAL  .LE.  IHIGH  .AND.  INTVAL  .SE.  ILQH  )  GO  TO  9999 

74 

150  CONTINUE 

75 

c 

76 

c 

Generate  an  error  aessage  indicating  that  the  response  was  outside 

77 

c 

of  the  expected  range. 

73 

c 

79 

WRITE  (  5.  900  )  (  TXTVAL(I),  I  =  I, ILEN  ) 

80 

WRITE  (  5,  902  )  ILOW,  IHIGH 

81 

GO  TO  10 

82 

900  FORMAT  (  1H  ,’****  INPUT  ERROR  ****  INPUT  VALUE  = 

83 

1  32A1  i 

84 

901  FORMAT  (  1H  ,’AN  INTEGER  INPUT  IS  REQUIRED,  PLEASE  TRY  AGAIN’,/) 

85 

902  FORMAT  (  1H  ,’AN  INTEGER  INPUT  BETWEEN  ’,15,’  AND  ’,15, 

-O 

CO 

1  ’  IS  REQUIRED,  PLEASE  TRY  AGAIN’/) 

87 

9999  CONTINUE 

88 

RETURN 

89 

END 

Prograa  Unit  Length=0239  (393)  Bytes 
Data  Area  Length=0187  (391)  Bytes 

Subroutines  Referenced: 

$12  $10  $AT 

PRSMEN  GETANS  PROHLP 

$W2  $ND 
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GETOBJ  is  called  by  both 


Processing  Description. 

EDTPRB  and  NEWPRB  whenever  a  problem  objective  is  to  be 
entered.  GETOBJ  prompts  the  user  -for  all  objective  in-for — 
mation  including,  objective  name,  objective  coef f icients, 
and  objective  type  (i.e.,  ma,-  .uze  or  minimize).  The  objec¬ 
tive  is  added  to  the  problem  as  objective  number  NOBJ  +  1. 

The  -first  question  GETOBJ  asks  the  user  is  -for  the 
objective  name.  I-f  the  user  is  done  entering  objectives 
(when  -first  defining  the  problem)  or  no  longer  wishes  to  add 
an  objective  (when  editing  the  problem),  he  indicates  this 
to  PCADA  by  responding  "/"  when  asked  for  the  objective 
name.  If  no  objective  is  added,  GETOBJ  sets  its  calling 
parameter  (II)  to  -1.  Upon  entry  to  GETOBJ,  II  is  set  to 
the  desired  objective  number 

Key  Local  Variables.  Refer  to  the  module  listing. 
Module  Listing.  The  following  pages  contain  the 
FORTRAN  compilation  listing  for  GETOBJ. 


FQRTRAN-80  Ver.  3.43  Copyright  1973-1981  (0  By  Microsoft  --  Bytes:  25131 
Created:  27-Jun-81 

1  SUBROUTINE  8ET0BJ  (  II  ) 

2  C 

3  C  Subroutine  8ET0BJ  --  Get  objective 

4  C 

5  C  This  subroutine  is  called  to  obtain  an  objective  function  froa  the 

6  C  user.  The  routine  returns  control  only  after  all  objective  in- 

7  C  foraation  is  obtained  or  after  the  user  indicates  his  desire  not  to 

8  C  enter  an  objective  function. 

9  C 

10  C  paraaeter  description  — 

11  C 

12  C  II  --  this  itea  contains  the  objective  nuaber  at  input  and  is  chang- 

13  C  ed  to  -1  only  if  the  user  decides  not  to  input  an  objective. 

14  C 

15  LOGICAL  TXTVAL (32) ,  F902X  <56> 

16  INTE6ER*!  CTYPEUOi,  QTYPE(4> .  NCON,  NOBJ ,  NVAR 

17  REAL  CON <10,10).  OBJ <4.10) ,  RHS(IO),  F802114) 

18  REAL *8  NAME,  FRAME,  CNAME(IO),  0NAHEI4) 

19  COMMON  !  FROB  i  CON.  CNAME,  CTYPE,  RHS,  OBJ.  CNAME,  OTYPE,  NCON, 

20  1  NOBJ,  NVAR,  FNAHE 

21  EQUIVALENCE  (  TXTVAL ( 1 ) ,  NAME  1,  (  F90211),  F902M)  ) 

22  BATA  F902  /  M43H’,  '  Ent’,  ’er  o’,  ’bjec’,  ’tive’,  ’  coe’, 

23  1  ’ffic’,  ’ient’,  ’  for’,  ’  var’,  ’iabl’,  ’e  x,’, 

24  2  ’I-,/’,  ’)  ’  / 

25  C 

26  C  first  ask  for  an  optional  naae  to  assign  to  the  objective 

27  C 

28  CALL  GETTXT  (  74,  0,  8,  0,  TXTVAL,  1  ) 

29  C 

30  C  a  naae  of  V*  indicates  that  there  are  no  sore  objectives. 

31  C 

32  IF  (  TXTVAL ( 1 )  ,NE.  X’2F’  )  GO  TO  30 

33  II  =  -1 

34  GO  TO  9999 

35  30  CONTINUE 

36  C 

37  C  save  the  nuaber  of  objectives  and  the  objective  naae.. 

38  C 

39  NOBJ  =  II 

40  ONAME(II)  =  NAME 

41  C 

42  C  call  8ETINT  to  find  out  if  this  is  a  aaxiaize  1=1)  or  a  minimize  i=2) 

43  C 

44  CALL  6ETINT  (  67,  0,  2,  1,  INTVAL  ) 

45  OTYPE (II)  =  INTVAL 

46  C 

47  C  loop  on  the  number  of  variables,  to  assign  the  coefficients  for  the 

48  C  constraint. 


50  DO  70  J  =  J,  NVAR 

51  F902X150)  =  X’31! 

52  IF  (  J  .EQ.  10  )  F902XI50)  =  X’32! 

53  WRITE  (  5.  F902  )  J 

54  C 

55  C  call  SETFLT  to  get  the  coefficient 

56  C 

57  CALL  SETFLT  (  71.  I.  99999.0,  -99999.0,  OBJ  III, J)  ) 

58  70  CONTINUE 

59  9999  CONTINUE 

60  RETURN 

61  END 

Prograi  Unit  Lenoth=011C  (284)  Bytes 
Data  Area  Length=0078  (120)  Bytes 

Subroutines  Referenced: 


$10 

$L3 

$ND 


8ETTXT 

$T3 

SETFLT 


BETINT 

$W2 


Variables: 


II 

0001* 

TXTVAL 

0003' 

F902X 

0023' 

CTYPE 

/PR.0B/+01E0 

OTYPE 

/PRQ8/+02D2 

NCON 

/PR0B/+02D6 

NOBJ 

/PR0B/+02D7 

NVAR 

/PR08/+02D8 

CON 

/PR0B/+0000 

OBJ 

/PRQ8/+0212 

RHS 

F902 

0023* 

NAME 

0003* 

FNANE 

/PR0B/+02D9 

CNAME 

/PR0B/+0190 

ONANE 

/PR08/+02B2 

T 1000002  0063' 

INTVAL 

0064' 

T: 000000  0066' 

J 

006E' 

t:  oioooo  0070 

COHNON  Length 
/PR0B/02E1  (737) 
Labels: 

30L  002B’ 


9999L  00F3’ 


70L 


OODF  ’ 
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GETPRB  —  Get  Problem  From  Disk 

Processing  Description.  DSKPRB  is  called  to  load  a 
problem  -file  -from  disk.  The  name  of  the  desired  file  is 
passed  as  one  of  the  calling  parameters  (NAME).  Since  all 
problem  files  are  stored  on  disk  with  the  file  type  "PRB", 
GETPRB  concatenates  the  file  type  designator  to  names  before 
attempting  a  disk  access. 

The  PCADA  System  uses  logical  unit  8  for  problem  files. 
GETPRB  closes  logical  unit  8  (via  ENDFILE)  before  attempting 
to  open  the  requested  file.  After  opening  the  file,  GETPRB 
attempts  to  read  all  problem  data  into  common  block  PROB. 
If  all  reads  are  successful,  then  problem  retrieval  is 
successful  and  control  reverts  to  the  calling  program.  An 
unsuccessful  read  indicates  that  one  of  the  following  has 
occurred: 


— disk  drive  door  open 
— problem  file  "NAME"  does  not  exist 
— diskette  is  bad 

— problem  diskette  is  not  installed. 


For  any  of  these  conditions,  GETPRB  sets  the  status  flag 
(ISTAT)  to  1  and  returns  control  to  the  calling  program 
(DSKPRB) . 

Kev  Local  Variables. 

IREC  —  Used  locally  as  the  problem  file  record  number. 
Incremented  as  the  file  is  processed. 

Module  Listing.  The  following  pages  contain  the 


FORTRAN  compilation  listing  for  GETPRB 


FORTRAN-80  Ver.  3.43  Copyright  1978-1981  (C)  By  Microsoft  --  Bytes:  25131 
Created:  27-Jun-81 

1  SUBROUTINE  6ETPRB  (  NAME.  ISTAT  ) 

2  C 

3  C  Subroutine  SETPRB  --  Get  Problea  froa  disk 

4  C 

5  C  This  subroutine  is  designed  to  retrieve  a  legal  problem  free  disk 

6  C  and  load  it  into  the  PROS  coaaon  block. 

7  C 

8  C  Paraaeter  descriptions  ---- 

9  C 

10  C  NAME  --  Contains  the  naae  of  the  desired  probles  Tile. 

11  C  ISTAT  —  Is  returned  to  the  calling  prograa  as  the  status  of  the 

12  C  problea  retireval  attempt .  A  value  of  zero  indicates  that 

13  C  all  Kent  sell  and  that  the  problea  is  loaded  into  the 

14  C  PROB  coaaon  block.  A  nonzero  value  indicates  that  soae 

15  C  sort  of  I/O  error  has  occured. 

16  C 

17  INTEGERS  CTYPE(IO),  OTYPE  (4) .  NCQN,  NOB J ,  NVAR 

13  LOGICAL  FlNAHE(ll),  TEMPI O) ,  NAME (8) 

19  REAL  CON (10, 10),  08,3(4,101,  RHS(IO) 

20  REAL»8  CNAME(IO),  0NAME(4),  FNAME 

21  COMMON  /  PROB  I  CON,  CNAHE,  CTYPE,  RHS,  OBJ.  0NAME,  OTYPE,  NC0N, 

22  1  NQBJ,  NVAR,  FNAME 

23  EQUIVALENCE  (  TEMPI (1),  FNAME  ) 

24  C 

25  C  Transfer  the  naae  of  the  desired  file  to  F1NAME. 

26  C 

27  DO  4  I  =  1,  8 

28  FINAME(I)  =  NAME(l) 

29  4  CONTINUE 

30  C 

31  C  Store  “PRBa  in  the  last  three  characters  of  F1NAME. 

32  C 

33  F1NAME (9)  =  X’50’ 

34  F 1  NAME  (10)  =  Jt’52’ 

35  F 1 NAME (11)  =  X’42’ 

36  C 

37  C  Initialize  the  status  flag  to  indicate  no  probles  occurred. 

33  C 

39  ISTAT  =  0 

40  C 

41  C  Check  to  see  if  the  problea  that  is  desired  is  already  active,  if 

42  C  it  is  than  no  further  action  by  GETPRB  is  necessary. 

43  C 

44  DO  B  I  =  1,  8 

45  IF  (  NAME(I)  .NE.  TEMPI (I)  )  GO  TO  9 

46  8  CONTINUE 

47  GO  TO  9999 

48  9  CONTINUE 


50 

c 

In  the  event  that  soae  other  problea  was  already  associated  Kith 

51 

c 

logical  unit  8,  kb  aust  hok  un-associate  it  to  allow  looking  at 

52 

c 

other  files,  and  to  aake  sure  that  the  previous  file  is  saved 

53 

c 

intact. 

54 

c 

55 

p 

ENDFILE  8 

j6 

57 

w 

c 

OPEN  the  new  proble®  file 

58 

c 

59 

L  i*i 

r 

CALL  OPEN  (  8,  FI NAME,  2  ) 

60 

61 

l 

c 

Attempt  to  read  the  first  record  Inuaber  of  constraints,  nunber  of 

62 

c 

objectives,  nuaber  of  variables) 

63 

c 

84 

READ  (  8,  £Rft=10.  END=10,  REC-1  )  NCDN,  NOBJ.  NVAR 

65 

GO  TO  20 

66 

10  CONTINUE 

67 

c 

68 

c 

Set  the  first  character  of  FRAME  to  */"  to  indicate  that  a  probles 

69 

c 

has  occured  and  that  the  PROS  data  can  not  be  trusted,  also  set 

70 

c 

1STAT  to  a  non-zero  value  to  indicate  that  all  is  not  well. 

71 

c 

72 

TEMPI (1)  =  X’2F’ 

73 

1STAT  =  1 

74 

GO  TO  9999 

75 

20  CONTINUE 

76 

c 

77 

c 

Loop  to  read  the  objective  function <s)  data. 

78 

c 

79 

DO  30  I  =  1,  NOBJ 

80 

IREC  s  I  +  1 

81 

READ  !  8.  ERR=10,  END=10,  REC=IREC  )  ONAMEil),  OTYPE(I), 

82 

1  (0BJ(I,J),  J  =  I,  NVAR  ) 

83 

30  CONTINUE 

84 

c 

85 

c 

Loop  to  read  the  contraint  data 

88 

c 

87 

DO  40  I  =  1,  NCON 

88 

IREC  =  I  +  1  +  NOBJ 

89 

READ  (  3,  ERRdO.  EN0=10,  REC=IREC  )  CNAMEI1),  CTYPE(I), 

90 

1  <  CON(I.J),  J  =  1,  NVAR  ),  RHS(I) 

91 

40  CONTINUE 

92 

c 

93 

c 

Store  the  nen  probleis  naee  into  FNAME  in  order  to  keep  track  of 

94 

c 

what  is  currently  loaded. 

95 

c 

96 

DO  50  I  =  1,  8 

97 

TEMPI (I)  =  NAME ! I ) 

98 

50  CONTINUE 

99 

9999  CONTINUE 

100 

RETURN 
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Progra*  Unit  Length=0274  (623)  Bytes 
Data  Area  Length=u037  (55)  Bytes 

Subroutines  Referenced: 


413 

$12 

$11 

FEN 

OPEN 

$R5 

$ND 

$N9 

Variables: 

NAME 

0001" 

1ST AT  0003“ 

CTYPE 

/PR0B/+01EO 

OTYPE 

/PRQ8/+02D2 

NCON  /PR0B/+02D6 

NOBJ 

/PR0B/+O2D7 

HVAR 

/PR0B/+02D8 

F INANE  0005* 

TEMPI 

/PRQB/+02D9 

CON 

/PRDB/+0000 

OBJ  /PR08/+0212 

RHS 

/PR0B/+01EA 

CNfiME 

/PR0B/+0190 

ONANE  /PRQB/+02B2 

FNAHE 

/PR0B/+02D9 

I 

0010“ 

T:  OOOOOO  0012* 

T:  010000  001' 

T : 02000C 

i  0016“ 

T: 000002  0018* 

IREC 

0023“ 

J 

002B' 

T:  030000  002D* 

T 1040000  0031 

COMMON  Length 
/PR0B/02E1  (737) 


Labels: 

4L  0028’  3L  007F’  9L  008F’ 

9999L  0263’  10L  00C1’  20L  00D3’ 


GETTXT  —  Get  Text 

Processing  Description.  GETTXT  is  one  of  the  PCADA 
input  processors.  It  is  designed  to  present  a  question  and 
obtain  a  text  value  in  response.  GETTXT  will  not  return 
control  to  the  calling  program  until  it  obtains  a  legal 
text  value  within  the  specified  length  range.  For  each  call 
to  GETTXT,  the  user  specifies  the  acceptable  item  length 
range  with  the  calling  parameters.  ILONG  indicates  the 
longest  acceptable  item  length  and  ISHORT  indicates  the 
shortest  acceptable  length.  Illegal  inputs  and  out  of 
length  range  values  will  cause  GETTXT  to  generate  an 
appropriate  error  message.  GETTXT  will  also  call  PROHLP 
when  needed  in  response  to  user  HELP  or  display  problem 
requests.  After  a  HELP,  a  display  request,  or  an  error 
message,  GETTXT  will  reask  the  question  and  look  for  a 
legitimate  text  response.  The  process  is  continued  until  a 
legal  text  value  is  obtained. 

Key  Local  Variables.  Refer  to  the  module  listing. 

Module  Listing.  The  following  pages  contain  the 


FORTRAN-90  Ver.  3.43  Copyright  1978-1981  (C)  By  Microsoft  --  Bytes:  25131 
Created:  27-Jun-81 

1  SUBROUTINE  6ETTXT  (  MENUIB,  MENSEM,  ILONG.  ISHORT,  TXTVAL.  I JUNK  ) 

2  C 

3  C  Subroutine  6ETTXT  —  Set  Test 

4  C 

5  C  Subroutine  6ETTXT  is  called  whenever  a  test  input  is  to  be  obtained 

6  C  froa  the  user.  This  subroutine  will  not  return  control  to  the 

7  C  calling  prograa  until  a  legal  text  value  whose  length  is  within  the 

8  C  specified  range  is  obtained.  Erroneous  inputs  result  in  the  gener- 

9  C  ation  of  an  appropriate  error  aessage  and  the  regeneration  of  the 

10  C  *enu  or  question.  If  the  user  should  input  *?'  or  "HELP',  6ETTXT 

11  C  will  call  PRSMEN  to  display  the  question’s  help  intoraation. 

12  C 

13  C  paraaeter  descriptions: 

14  C 

15  C  MENUID  --  Contains  the  identification  of  the  desired  aenu. 

14  C  MENSEM  --  Specifies  whether  or  not  the  aenu  is  to  be  displayed.  In 

17  C  soae  cases,  the  calling  prograa  aay  have  generated  a 

18  C  variable  aenu,  and  just  desire  the  answer.  Setting 

19  C  MENSEM  to  a  noncero  value  will  suppress  the  generation 

20  C  of  the  aenu. 

21  C  ILQNS  —  This  itea  contains  the  length  of  the  longest  test  ite# 

22  C  that  is  acceptable  for  this  input. 

23  C  I SHORT  —  This  itea  contains  the  length  of  the  shortest  text  ite* 

24  C  that  is  acceptable  for  this  input. 

25  C  TXTVAL  —  This  itea  is  returned  to  the  calling  prograa  containing 

24  C  the  user’s  input  text  value. 

27  C  I JUNK  --  This  itea  indicates  that  any  text  string  is  allowed  if 

23  C  it  is  set  to  one  at  entry. 

2?  C 

30  LOGICAL  TXTVAL <32) ,  INDATA ( 128) 

31  10  CONTINUE 

32  C 

33  C  deteraine  if  the  aenu  should  be  generated  for  this  text  request, 

34  C  if  so,  call  PRSMEN  to  display  it. 

35  C 

34  IF  (  MEN6EN  .HE.  0  )  SO  TO  20 

37  CALL  PRSMEN  (  MENUIB.  0  ) 

38  20  CONTINUE 

39  1!  *  1 

40  C 

41  C  Blank  out  TXTVAL  before  getting  inout. 

42  C 

43  B0  25  I  =  1.  RONS 

44  TXTVAL (I)  =  X’20’ 

45  25  CONTINUE 

44  C 

47  C  Call  GETANS  to  get  another  input  bead  froa  the  user. 

48  C 

49 


CALL  GETANS  (  INDATA,  I  TYPE.  1NTVAL,  FPVAL,  TXTVAL,  ILEN, 


1 


Ii,  I HELP  i 


50 

51  C 

52  C  Check  to  deteriine  if  the  user  has  requested  help, 

53  C 

54  IF  (  1HELP  ,E8,  0  )  80  TO  30 

55  CALL  PRQHLP  (  1HELP,  MENUID  ) 

56  GO  TO  10 

57  30  CONTINUE 

58  C 

59  C  Deteriine  if  8ETANS  has  found  a  text  i tea 

60  C 

61  IF  (  I  TYPE  ,E8.  3  .OR.  IJUNK  .  NE.  0  )  GO  TO  50 

62  45  CONTINUE 

63  WRITE  (  5.  900  )  (  TXTVAL ( I) .  I  =  1.  ILEN  > 

64  WRITE  (  5,  901  ) 

65  GO  TO  10 

66  50  CONTINUE 

67  C 

68  C  Determine  if  the  users  input  is  within  the  specified  lenoth  rannp 

69  C 

70  IF  i  ILEN  ,LE.  ILONG  .AND.  ILEN  .GE.  ISHORT  )  GO  TO  60 

71  WRITE  (  5.  900  )  (TXTVAL(I) ,  I  =  1.  ILEN  ) 

72  WRITE  (  5.  902  )  ISHORT.  ILONG 

73  GO  TO  10 

74  60  CONTINUE 

75  C 

76  C  Check  to  see  if  the  itea  was  of  length  zero, 

77  C 

78  IF  (  ILEN  .EQ.  0  .OR.  I JUNK  .NE.  0  1  GO  TO  70 

79  C 

80  C  Make  sure  that  the  text  input  was  a  legal  text  value. 

81  C  First  character  gust  be  a  letter,  and  retaining  characters  Bust 

82  C  be  digits  or  letters,  no  special  characters  are  aliened,  and  no 

83  C  lowercase  letters  are  allowed. 

84  C 

85  IF  (  TXTVAL(l)  ,6T.  X’5A’  .OR. 

86  1  TXTVAL < 1 )  ,LT.  X’41’  )  GO  TO  45 

87  DO  70  I  =  1,  ILEN 

88  IF  !  (  TXTVAL (1)  ,LE.  X’5A'  .AND. 

89  1  TXTVALU)  .GE.  X’41’  )  .OR. 

90  2  (  TXTVAL(I)  .LE.  X’39’  .AND. 

91  3  TXTVAL (I)  .GE.  X’30’  1  )  60  TO  70 

92  GO  TO  45 

93  70  CONTINUE 

94  900  FORMAT  (  1H  ,’****  INPUT  ERROR  **♦*  INPUT  VALUE  =  ’. 

95  1  32A1  1 

96  901  FORMAT  (  1H  . ’TEXT  INPUTS  MUST  BEGIN  WITH  A  LETTER  AND  MAY  \ 

97  1  ’CONTAIN  NO  SPECIAL  CHARACTERS’,/) 

98  902  FORMAT  (  1H  ,’A  TEXT  INPUT  BETWEEN  M2.’  AND  ’.12. 

99  1  ’  CHARACTERS  IN  LENGTH  IS  REQUIRED.’,/) 

100  9999  CONTINUE 
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Processing  Description.  This  subroutine  is  called  to 
solve  a  single  objective  linear  programming  problem.  It  is 
called  iteratively  within  the  PC-ADA  system  as  part  of  the 
mul t i ob j ect i ve  problem  solution  process. 

LP  utilizes  the  SIMPLEX  method  as  described  in  "Linear 
Programming  and  Extension"  by  Wu  and  Coppins.  As  implement¬ 
ed,  this  subroutine  is  limited  to  problems  with  10  con¬ 
straints  and  10  variables.  The  program  expects  constraint 
in-formation  to  be  stored  by  the  calling  program  in  the  array 
D.  The  constraints  must  be  entered  in  the  -following  order: 

1 .  greater  thans  or  equal 

2.  equals 

3.  less  thans  or  equal 

In  addition,  the  objective  -function  must  be  in  the  form  to 
be  maximized.  Thus  in  PCADA  the  calling  program  must  invert 
(i.e.  multiply  by  -1)  MINIMIZE  objectives. 

When  LP  is  called,  the  RHS  value  for  each  constraint  is 
stored  in  the  last  element  of  D  (i.e.  D<i,31>).  LP  moves 
this  value  to  the  last  active  column  as  determined  by  the 
number  of  constraints  and  variables. 

The  "big  M"  method  is  used  for  artificial  variables.  LP 
initializes  correspondi ng  objective  coefficients  to  —99999.0 
for  this  purpose. 

LP  indicates  the  occurrence  of  a  special  condition 


through  the  return  flag  (IW). 


If  no  pivot  row  can  be  found 


R0-ftl5i  911  PERSONAL  COMPUTER  HIDED  DECISION  ANALYSIS(U)  AIR  FORCE 
INST  OF  TECH  HRIGHT-PATTERSON  AFB  OH  SCHOOL  OF 
ENGINEERING  G  R  WHITE  14  DEC  84  AFIT/GS0/0S/84D-8 

F/G  9/2 


UNCLASSIFIED 


microcopy  resolution  test  chart 

NAIIONAL  BURlAU  OF  SFANDARDS  !%..<  A 


then  IW  is  set  to  -1  to  indicate  that  the  problem  is 
unbounded.  It  the  process  terminates  "normal  1 y" ,  the  basis 
is  examined  to  see  it  it  includes  an  artiticial  variable. 
It  so,  the  problem  is  inteasible  and  LP  indicates  this  by 
setting  IW  to  -2.  Finally,  LP  avoids  the  degeneracy  problem 
by  using  the  techniques  suggested  in  Wu  and  Coppins. 

The  program  does  not  check  tor  the  multiple  optimal 
condition  but  could  be  adjusted  to  do  so  as  noted  in  the 
comment  at  the  program’s  end. 

Key  Local  Variables. 

NEG  —  Detines  the  starting  column  number  tor  the  artiticial 
variables. 


NEE  —  Detines  the  ending  column  number  tor  the  artiticial 
variables. 

SUM  —  This  variable  contains  the  value  reterred  to  as  Zj" 
in  Wu  and  Coppins. 

SC  —  This  variable  contains  the  value  reterred  to  as  "Cj  - 
Z j "  in  Wu  and  Coppins. 

SCMAX  —  This  variable  contains  the  smallest  ”Cj  —  Z j “ 
value  and  is  used  when  searching  tor  the  entering 
variable  (pivot  col). 

SMVAL  —  This  variable  contains  the  smallest  ratio  (basic 
variable  to  the  corresponding  coetticient)  that  is 
used  when  searching  tor  the  leaving  basic  variable 
(pivot  row) . 

IPIVC  —  This  variable  identities  the  pivot  column. 

IPIVR  —  This  variable  identities  the  pivot  row. 

Module  Listing.  The  tol lowing  pages  contain  the 

FORTRAN  compilation  listing  tor  LP. 


FGRTRAN-SQ  Ver.  3.43  Copyright  1978-1981  (C)  By  Microsoft  --  Bytes:  25131 
Created:  27-Jun-Sl 

1  SUBROUTINE  LP  (Ilf.  12.  IY,  IA,  NEQ  ) 

2  C 

3  C  This  subprograa  is  invoked  to  solve  a  linear  progressing  problea. 

4  C  The  SIMPLE!!  process  is  used,  as  described  in  'Linear  Prograaaing 

5  C  and  Extensions”  by  Nu  &  Coppins  (copyright  1931).  All  paraaeters 

6  C  are  input  paraaeters  except  for  IBV  which  is  output  and  IN  which 

7  C  is  input  and  output.  Paraaeters  are  used  as  follows: 

8  C 

9  C  IN  is  input  as  the  nuaber  of  constraints  and  output  to  indicate 

10  C  the  occurence  of  a  special  case: 

11  C  -1  teans  the  problea  is  unbounded 

12  C  -2  aeans  the  solution  is  infeasible 

13  C  IZ  is  the  total  nuaber  of  aatrix  coluans  +  1 

14  C  (i.e.  of  variables  +  of  equal  constraints  +  of  less  than 

15  C  constraints  +  2  tiaes  the  of  greater  than  constraints  +  1) 

•16  C  IY  is  the  nuaber  of  problea  variables  +  1 

17  C  IA  is  the  nuaber  of  greater  than  constraints 

18  C  NEQ  is  the  nuaber  of  equal  constraints 

19  C  P  is  the  array  of  objective  coefficients 

20  C  D  is  the  two  diaensional  array  of  constraints  coefficients 

21  C  note!  D(I,IZ)  contains  the  right  hand  sides 

22  C  IBV  is  output  as  the  array  of  basic  variables 

23  C  i.e,  IBV (3)  =  5  says  that  X5  is  in  the  solution  and  that 

24  C  D(3,1Z)  contains  the  value  of  15. 

25  C 

26  C  This  prograa  is  United  to  10  constraints,  10  variables,  and  the 

27  C  constraints  Bust  be  entered  in  the  followino  order: 

28  C 

29  C  1.  greater  thans 

30  C  2.  equals 

31  C  3.  less  thans 

32  C 

33  C  The  objective  function  aust  be  in  a  fora  to  be  aaxiaized. 

34  C  The  prograa  includes  the  suggestions  aade  in  Nu  4  Coppins 

35  C  for  avoiding  the  degeneracy  problea. 

36  C 

37  DIMENSION  P(30).  DUO, 31),  ISV(IO),  SC(30) 

38  INTEGERS  I,J,H,N 

39  INTEGERS  SPCPL8,  VARNU»(3D,K»,  CNXREFI10) 

40  REAL  ZF (4) ,  0BJVAL (30, 4) ,  VARVAU30. 10) 

41  REAL  N(4) ,  UB<4),  LB(4>,  DELI4),  S0LNHT(30,4),  UBWHT (4) 

42  COMMON  /  S0LN  /  N.  UB.  LB.  DEL,  ISTRT,  P,  D,  IBV,  S0LNHT ,  VARNUM, 

43  1  VARVAL,  0BJVAL,  ZF,  MMDS,  CNXREF,  SPCFLS,  UBMHT , 

44  2  ICAP 

45  C 

46  C  set  IX  equal  to  the  nuaber  of  coluans  in  the  aatrix 

47  C 

48  IX  =  IZ  -  1 

49  C 
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C  initialize  aatrix  data 
C 

DO  4  1  =  1,  1H 
Oil. IZ)  =  0(1,31) 

4  CONTINUE 
DO  S  I  =  IY,  IK 
P(I)  =  0.0 
DO  6  J  =  1,  IN 
DU, I)  =  0,0 
&  CONTINUE 
8  CONTINUE 
C 

C  initialize  “BIG  ft*  coefficients  for  artificial  variables,  if  any 
C 

IF  I  (IA  +  NE9)  .EO.  0  )  GO  TO  20 
NE6  =  IV  ♦  IA 
NEE  =  NE6  +  IA  -  1  +  NEQ 
DO  10  1  =  NES,  NEE 
P(I)  =  -99999.0 
10  CONTINUE 
20  CONTINUE 
C 

C  initialize  the  identity  and  identify  the  starting  basis  in  IBV 
C 

DO  40  I  =  1,  IN 
J  =  I  *  IY  ♦  IA  -  1 
D(I.J)  =  1.0 
1BV1I)  =  i 
40  CONTINUE 
C 

C  initialize  for  the  artificial  variables 
C 

IF  (  IA  .EQ.  0  )  GO  TO  100 
DO  50  I  =  1,  IA 
J  =  I  +  IY  -  1 
D  ( I . J )  =  -1.0 
50  CONTINUE 
100  CONTINUE 
SCPIAX  =  0.0 

c 

C  search  for  and  select  pivot  colmn 
C  note:  SUN  =  "Zja  and  P( j)  =  ’Ci' 

C 

DO  130  1=1,  IX 
SUM  =  0.0 
DO  110  J  =  1,  IN 
N  =  IBV(J) 

SUN  =  SUN  +  P(N)  »  DU, I) 

110  CONTINUE 

SC(I)  =  P( I)  -  SUN 

IF  (  SC(I)  .LE,  SCNAX  )  GO  TO  130 


IPIVC  *  I 
130  CONTINUE 
C 

C  select  pivot  row 

C  at  this  point,  if  SCMAX  =  0  then  solution  is  coaplete 
C 

IF  (  SCMAX  .LE.  0.0  )  60  TO  210 
SNVAL  =  99999999. 

IPIVR  *  0 
DO  160  H  =  1,  IN 

IF  I  DIN. IPIVC)  .LE.  0.0  )  60  TO  160 
QUONT  =  DIM. I Z )  /  DIH, IPIVC) 

IF  1  SHVAL  .LE.  BUONT  )  SO  TO  160 
IPIVR  =  H 
SHVAL  =  BUONT 
160  CONTINUE 
C 

C  perfor*  the  pivot 

C  First,  adiust  the  pivot  row,  then  do  the  pivot 
C 

IF  (  IPIVR  .Efl.  0  )  60  TO  205 
IBV(IPIVR)  =  IPIVC 
DIV  =  D1IPIVR, IPIVC) 

DO  170  N  -  1,  IZ 
D1  IPIVR, N)  =  DUPIVR.N)  /  DIV 
170  CONTINUE 
DO  200  H  =  i, 

IF  (  H  .EQ.  IPIVR  )  60  TO  200 

cn  =  -Din, ipivc) 

DO  190  N  =  1,  IZ 

D1H.N)  =  D(N.N)  ♦  (  DUPIVR.N)  #  CH  ) 

190  CONTINUE 
200  CONTINUE 
C 

C  now  go  back  and  do  another  pivot 
C 

GO  TO  100 
205  CONTINUE 
C 

C  set  IN  to  indicate  that  the  probiea  is  unbounded 
C 

IN  =  -1 
GO  TO  230 
210  CONTINUE 
C 

C  for  ncnal  finish,  aust  now  look  to  see  if  the  basis  contain 
C  artificial  variable,  if  so.  the  proble*  is  infeasible. 

C 

IF  1  UA+NEB)  .EB.  0  )  60  TO  230 
DO  220  1=1.  IN 


152  IF  <  IBV(l)  .LT.  NE6  .OR.  IBV(I)  .6T.  NEE  )  SO  TO  220 

153  SUN  :  ABS  (  DU,  12)  ) 

154  IF  (  SUN  .LT.  0,001  )  60  TO  220 

155  IN  =  -2 

156  60  TO  230 

157  220  CONTINUE 

158  C 

159  C  Note:  At  this  point,  one  could  check  for  aultiple  optisal 

160  C  by  seeing  if  Zj  -  Cj  =  0  for  any  j  (non-basic 

161  C  variables  only). 

162  C 

163  230  CONTINUE 

164  RETURN 

165  END 

Progran  Unit  Length=0637  (1591)  Bytes 
Data  Area  Length=0083  (179)  Bytes 


Subroutines  Referenced: 


ABS 

$AT 

$N9 

)L1 

*T1 

tMB 

(AB 

$SB 

♦DB 

<NB 

Variables: 

IN 

0001' 

IZ 

0003" 

IV 

0005" 

IA 

0007" 

NE6 

0009" 

P 

/S0LN/+0042 

D 

/SQLN/+OOBA 

IBV 

/SQLN/+0592 

SC 

OOOB* 

I 

0083" 

J 

0084" 

H 

0085" 

N 

0086" 

SPCFL6 

/S0LN/+0F5E 

VARNUN 

/S0LN/+0786 

CNXREF 

/SQLN/+GF54 

ZF 

/S0LN/+0F42 

OBJVAL 

/S0LN/+0D62 

VARVAL 

/S0LN7+08B2 

N 

/SOLN/+COOO 

UB 

/SQLN/+0010 

LB 

/S0LN/+0020 

DEL 

/S0LN/+0030 

SOLNHT 

/S0LN/+05A6 

UBNHT 

/S0LN/+0F5F 

ISTRT 

/SOLN/+0040 

NNDS 

/S0LN/+0F52 

ICAP 

ZSOLN/+OF6F 

U 

0087" 

T: 000000  0089 

TJOIOOOO  008B* 

T: 000002 

1  008D" 

NE6 

008E" 

NEE 

0090" 

T: 020000  0092* 

SCMAX 

0094* 

SUN 

0098" 

IPIVC 

009C" 

SNVAL 

009E" 

IPIVR 

00A2" 

OUONT 

00A4" 

DIV 

00  A8" 

CN 

OOAC" 

T: 030000 

i  OOBO" 

T: oiooo 

2  00B2' 

COMMON  Length 
/S0LN/0F71  (3953) 


NEWPRB  —  De-fine  New  Problem 

Processing  Description.  This  routine  is  called  when 
the  user  indicates  that  he  wants  to  enter  a  new  problem  -for 
PCADA  processing.  First,  the  user  is  asked  -for  an  eight 
character  name  -for  the  problem.  It  the  user  responds 
"STOP",  it  indicates  that  he  has  changed  his  mind  about 
entering  a  new  problem,  and  control  is  returned  to  the 
calling  program.  For  all  other  names,  NEWPRB  calls  GETPRB 
to  determine  it  the  name  is  already  in  use.  It  it  is,  the 
user  is  given  the  option  ot  using  it  anyway  (and  losing  the 
original  tile)  or  ot  speci tying  a  new  name. 

Atter  an  acceptable  name  has  been  obtained,  NEWPRB  will 
ask  the  user  how  many  variables  the  problem  is  to  contain. 
Next,  the  user  is  asked  tor  the  objectives  and  constraints. 

When  all  problem  data  has  been  entered,  NEWPRB  calls 
SAVPRB  to  write  the  new  problem  tile  to  disk. 

Key  Local  Variables.  Reter  to  the  module  listing 


The  toll  owing 


pages  contain  the 


FORTRAN-80  Ver.  3.43  Copyright  1978-1981  (C)  By  Microsoft  --  Bytes:  25131 
Created:  27-Jun-81 

1  SUBROUTINE  NENPRB 

2  C 

3  C  Suoroutine  NENPRB  --  Define  new  problei 

4  C 

5  C  This  subroutine  is  designed  to  allow  the  user  to  define  a  new 

6  C  iultiobjective  problei  to  be  solved  by  PCADA.  When  called,  this 

7  C  subroutine  will  pro*pt  the  user  for  all  of  the  required  data  and 

8  C  will  then  save  the  problei  to  disk  for  later  reference. 

9  C 

10  C  there  are  no  input/output  paraseters  for  this  subroutine 

11  C 

12  L081CAL  TXTVAL (32) 

13  INTEGERS  CTYPE(IO),  0TYPE14),  NCGN,  NQ8J,  NVAR 

14  REAL  CON (10,10),  08J(4,10),  RHSI10) 

15  REAL»8  NAME,  FNAME,  CNAME(IO),  QNAME14) 

lb  COMMON  /  PROS  /  CON.  CNAME,  CTYPE,  RHS.  OBJ.  ONAME.  OTYPE,  NCON. 

17  1  NQBJ,  NVAR,  FNAME 

18  EQUIVALENCE  (  TXTVAL  <  1  > .  NAME  ) 

19  C 

20  C  clear  the  screen 

21  C 

22  WRITE  (  5,  900  ) 

23  C 

24  C  display  an  opening  blurb  to  the  user  describing  what  a  problei  is 

25  C  and  that  he  is  now  going  to  define  one. 

2b  C 

27  CALL  PRSMEN  (  48,  0  ) 

28  10  CONTINUE 

29  C 

30  C  call  GETTXT  to  find  out  what  the  user  wants  to  call  this  probles 

31  C  for  saving  on  disc,  nases  can  be  froi  2  to  8  characters  in  length 

32  C  no  special  characters  are  allowed. 

33  C 

34  CALL  GETTXT  (  54,  0,  8,  2,  TXTVAL,  0  ) 

35  C 

3b  C  see  if  the  user  responded  to  the  question  with  “STOP",  indicating 

37  C  he  real  1 v  does  not  want  to  define  a  new  problei  now. 

38  C 

39  IF  (  TXTVAL (1)  .E8.  X’53’  .AND.  TXTVAL (2)  .EQ.  X’54’  .AND. 

40  1  TXTVAL (3)  .E9.  X’4F’  .AND.  TXTVAL  1 4)  .E8.  X’50’  .AND. 

41  2  TXTVAL(j)  ,E9.  X’20’  )  GO  TO  9999 

42  C 

43  C  call  GETPRB  for  the  purpose  of  detersining  if  there  already  is  a 

44  C  problei  file  nate  that  is  the  sale  as  what  the  user  wants  to  call 

45  C  this  one. 

4b  C 

47  CALL  GETPRB  (  NAME.  ISTAT  ) 

48  C 

49  C  A  status  value  of  rero  indicates  that  a  proble*  was  correctly  loaded 


C  ie.  a  file  already  exists  wi th  the  naae  that  the  user  specified. 

C 

IF  (  ISTAT  .NE.  0  )  SO  TO  40 
C 

C  call  GETINT  to  tell  the  user  that  the  file  already  exists  and  ask  hit 
C  if  this  Mas  intentional.  If  so,  allow  hie  to  redefine  using  that 
C  file,  if  not.  ask  for  a  neu  file  naae. 

C 

CALL  GETINT  (  58,  0,  2,  1.  1NTVAL  ) 

IF  !  1NTVAL  ,E9.  2  )  80  TO  10 
40  CONTINUE 
C 

C  assign  the  user  specified  naae  to  FNANE 
C 

FNAME  =  NANE 
C 

C  call  6ETINT  to  ask  the  user  Hom  aany  variables  his  probles  is  to 
C  contain 
C 

CALL  GETINT  (  S3.  0.  10,  1,  IMTVAL  ) 

NVAR  =  INTVAL 
C 

C  enter  loop  to  get  the  objectives... note  aaxiaua  of  4. 

C 

N06J  =  0 
DO  80  I  =  1,  4 
WRITE  (  5,  901  )  I 
11  =  1 

CALL  6ET08J  (  II  ) 

IF  (  II  .E8.  -1  )  GO  TO  85 
80  CONTINUE 
85  CONTINUE 

IF  (  NOBJ  .NE.  0  )  GO  TO  88 
WRITE  (  5,  902  ) 

GO  TO  10 
88  CONTINUE 
NCON  *  0 
C 

C  loop  to  obtain  the  constraints  for  this  problea.  note  the  aaxiaua 
C  of  10. 

C 

DO  120  1=1,  10 
WRITE  1  5,  904  )  I 
II  =  1 

CALL  GETCON  (  II  ) 

IF  I  II  .EQ.  -1  )  GO  TO  125 
120  CONTINUE 
125  CONTINUE 

IF  (  NCON  .NE.  0  )  GO  TO  130 
WRITE  (  5,  902  ) 

GO  TO  10 


101  130  CONTINUE 

102  C 

103  C  call  SAVPRB  to  save  the  newly  defined  probles  to  disk. 

104  C 

105  CALL  SAVPRB  (  ISTAT  ) 

106  900  FORMAT  (  1H1  ) 

107  901  FORMAT  (  1H1.  ’OBJECTIVE  FUNCTION  ’,11,/) 

108  902  FORMAT  (  1H  .’§**♦  INVALID  PROBLEM-MUST  HAVE  AT  LEAST  ONE  ’ 

109  1  ’OBJECTIVE  AND  CONSTRAINT  **#*%/) 

110  904  FORMAT  (  1H1,  ’CONSTRAINT  ’,12,/) 

111  9999  CONTINUE 

112  RETURN 

113  END 

Progra*  Unit  Length=01CA  (458)  Bvtes 
Data  Area  Length=00DA  (218)  Bytes 

Subroutines  Referenced: 


$10 

$W2 

$ND 

PRSMEN 

6ETTXT 

BETPRB 

GETINT 

$L3 

$T3 

GETOBJ 

SETCON 

SAVPRB 

Variables: 

TXTVAL 

0001" 

CTYPE 

/PR0B/+01E0 

OTYPE 

/PRQB/+0202 

NCQN 

/PR08/+02D6 

NDBJ 

/PROB/+02D7 

NVAR 

/PR0B/+02D8 

CBN 

/PR0B/+0000 

OBJ 

/PR0B/+0212 

RHS 

/PR0B/+01EA 

NAME 

0001' 

FNAME 

/PR0B/+02D9 

CNAME 

/PR0B/+0190 

ONAME 

/PR0B/+02B2 

T:  000002  0029* 

T: oioooi 

!  002A1 

T 1020002  002B* 

T: 030002  002C* 

T: 040002  002D 

ISTAT 

002E" 

INTVAL 

0030* 

I 

003E* 

II  0040* 


COMMON  Length 
/PR0B/02E1  (737) 


Labels: 


900L 

0042* 

10L 

0015’ 

9999L 

01A1  ’ 

40L 

00A9’ 

80L 

0108’ 

901L 

0047* 

B5L 

0115’ 

SSL 

0131’ 

902L 

0069* 

I20L 

0172’ 

904L 

OOCO" 

125L 

01 7F’ 

130L  019B’ 
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PCADA  —  Main  Program 

Processing  Description.  PCADA  is  the  system’s  main 
program.  Its  purpose  is  to  initialize  the  system,  open  the 
necessary  -files,  determine  what  the  user  wants  to  do,  and 
then  call  the  appropriate  -function. 

First,  PCADA  opens  the  menu/help  -file  and  assigns 
logical  unit  7  to  it.  Next,  PCADA  presents  the  user  with 
some  general  instructions  and  then  asks  him  to  speci-fy 
whether  he  wants  to  load  a  -file  -from  disk  or  de-fine  a  new 
one.  At  this  point,  these  are  the  only  options  since  a 
problem  must  be  identified  before  it  can  be  solved  or 
modified.  Once  a  problem  has  been  identified,  the  user  is 
presented  with  system  level  menu  2.  This  menu  gives  the 
user  the  following  options: 

-  load  a  new  problem  from  disk 

-  define  a  new  problem 

-  edit  the  problem 

-  solve  the  problem 

Based  on  the  user’s  response,  PCADA  calls  the  appropriate 
function.  When  the  requested  process  is  completed,  control 
again  reverts  to  PCADA  where  the  user  is  again  faced  with 
system  level  menu  2  for  his  next  request.  Processing  con¬ 
tinues  in  this  fashion  until  the  user  indicates  he  wishes  to 
exit. 

Kev  Local  Variables.  Refer  to  the  Module  Listing. 

Module  Listing.  The  following  pages  contain  the 
FORTRAN  compilation  listing  for  PCADA. 
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FCRTRAN-90  Ver.  3.43  Copyright  1978-1981  (0  By  Mic-osoft  --  Bytes!  25131 
Created:  27-Jun-81 

1  PROGRAM  PCADA 

2 


3  C*  * 

4  C»  PROGRAM  PCADA  -  PERSONAL  COMPUTER  AIDED  DECISION  ANALYSIS  * 

5  C*  * 

6  C*  This  progra*  was  written  as  part  of  thesis  effort  in  partial  * 

7  C*  fulfill  sent  of  the  requiresents  for  the  degree  of  Master  of  * 

B  C»  Science  in  Space  Operations  fro*  the  Air  Force  Institute  of  * 

9  C*  Technology,  Deceaber  1984.  * 

10  C*  * 

11  C*  Author:  Sreg  R.  White  * 

12  C*  Academe  Advisor:  Lt.  Col.  Mark  Mekaru  * 

13  C*  Thesis  Reader:  Mai.  Ken  Feldaan  * 

14  C*  » 

15  C*  The  progra*  is  designed  to  solve  cosplex  *ultiobjective  decision  * 

14  C*  analysis  proble»s.  The  objectives  of  the  research  were  to  deso-  * 

17  Ct  strate  that  such  a  progra*  could  be  written  for  a  personal  coa-  * 

18  C*  puter  in  a  user  friendly,  easy  to  use  fashion.  This  prograa  * 

19  C*  was  originally  written  in  CP/M  based  FORTRAN  80.  Although  * 

20  C*  first  hosted  on  an  Apple  II  Plus  coaouter,  the  prograa  does  not  * 

21  C»  take  advantage  of  any  special  Apple  features,  and  can  thus  be  * 

22  C*  rehosted  to  any  coaparable  Z80  based  computer  system  * 

23  C*  * 


24  Ci*****»**t****t****«*M*MM*M*M*Mt*tM**m«M«*****tt**t***»i* 

25  C 

24  INTEGER  ACTHEN,  IBVU01 

27  LOGICAL  TITVAU32),  MENVALI748),  TEMP (8) 

28  INTEGERS  SPCFLG,  VARNUM(30,10),  CNXREF(IO) 

29  INTEGERS  CTYPE(IO),  0TYPE14),  NCON,  NOBJ,  NVAR,  MENSIZ.  HENLIN, 

30  1  HLPSIZ,  HLPLIN,  MLNSZ (12) ,  HLNSZ112) 

31  REAL  ZF (4) ,  0BJVAL(30,4),  VARVAL (30, 10) ,  S0LWHT (30, 4> ,  UBHHTI4) 

32  REAL  0(4),  UB(4),  LB(4),  DEL(41,  P(301,  DUO, 31) 

33  REAL  CON (10, 10) ,083(4,101 ,RH5(10) 

34  REAL*3  CNAHE ( l 0 ) , OH AME ( 4 ) , FNAME 

35  C 

36  C  The  following  co*aon  block  (  PR0B  )  is  used  throughout  this  prograa 

37  C  as  a  storage  area  for  data  to  describe  the  problem  currently  under 

38  C  consideration  by  the  user. 

39  C 

40  C  CON  --  This  10  bv  10  array  is  used  to  contain  the  constraint 

41  C  coefficients.  The  di*ensions  correspond  to  the  fact  that 

42  C  there  are  a  aaxiau*  of  10  constraints  with  a  saxiau*  of  10 

43  C  variables  each. 

44  C 

45  C  CNAME  --  This  10  eleaent  array  is  used  to  contain  the  constraint 

46  C  name.  This  optional  naae  is  input  be  the  user  when  the 

47  C  profal e«  is  created. 

48  C 

49  C  CTYPE  —  This  10  element  array  is  used  to  contain  the  constraint 


C  relationship  as  foil oms: 

C  1  =  less  than  or  eoual  constraint 

C  2  =  equal  constraint 

C  3  =  greater  than  or  equal  constraint 

C 

C  RHS  —  This  10  elesent  array  is  used  to  contain  the  constraint 
C  right  hand  side  values. 

C 

C  OBJ  —  This  4  by  10  eleaent  array  contains  the  object i ve  co- 
C  efficients.  There  can  be  up  to  4  objective  functions, 

C 

C  ONfiHE  --  This  4  eleaent  array  is  used  to  contain  the  objective 
C  naae.  This  optional  nase  is  input  by  the  user  when  the 

C  problea  is  created. 

C 

C  OTYPE  --  This  4  eleaent  array  is  used  to  contain  the  objective  tvpe 
C  as  follows: 

C  1  =  MAXIMIZE 

C  2  =  MINIMIZE 

C 

C  NOON  —  This  itea  contains  the  nuaber  of  constraints  in  the  current 
C  problea, 

C 

C  NOBJ  —  This  itea  contains  the  nuaber  of  objective  functions  in  the 
C  current  problea. 

C 

C  NVAR  --  This  itea  contains  the  uaber  of  variables  in  the  current 
C  prcbles, 

C 

C  FNArlE  —  This  itea  contains  the  naae  of  the  current  problea.  Prob- 
C  leas  are  stored  on  disk  using  this  naae  with  a  file  type  of 

C  'PRB\ 

C 

COMMON  /  PROS  /  CON.  CNAHE,  CTYPE,  RHS,  OBJ..  ONAHE.  OTYPE,  NCON. 

1  NOBJ.  NVAR.  FNAHE 

C 

C  The  following  coaaon  block  (  MENDAT  )  contains  inforaation  relating 
C  to  the  currently  'active0  aenu. 

C 

C  NENSIZ  —  This  itea  contains  the  nuaber  of  records  that  the  current 
C  aenu  occupies  on  disk.  NOTE:  disk  records  are  123  char- 

C  acters  long. 

C 

C  MENLIN  —  This  itea  contains  the  nuaber  of  lines  that  the  current 
C  aenu  occupies  on  the  screen. 

C 

C  HLPSIZ  --  This  item  contains  the  nuaber  of  records  that  the  HELP 
C  aessage  associated  with  the  current  aenu  occupies  on  disk. 

C 

C  HLPLIN  —  This  itea  contains  the  nuaber  of  lines  that  the  HELP  ses- 
C  sage  associated  with  the  current  aenu  occuoies  on  the 


screen. 


MLNSZ  —  This  12  eleaent  array  contains  the  sire,  in  characters  of 
each  of  the  MENLIN  lines  of  the  current  aenu.  NOTE:  the 
diaension  of  this  array  liaits  the  nuaber  of  lines  in  each 
aenu  to  12. 

HLNSZ  --  This  12  eleaent  array  contains  the  size,  in  characters  of 
each  of  the  HLPLIN  lines  of  the  HELP  aessage  associated 
with  the  current  aenu. 

MENVAL  --  This  769  eleaent  array  contains  the  actual  characters  that 
aake  up  the  current  aenu  and  its  help  aessage.  The  768 
eleaents  corresponds  to  6-128  character  records.  The  first 
MENSIZ  records  (  i.e.  128  *  MENSIZ  characters  )  contains 
the  aenu  data  and  the  next  HLPSIZ  records  contains  the  HELP 
data. 

ACTMEM  —  This  i tea  contains  the  identity  of  the  current  aenu.  Menus 
are  identified  by  there  starting  diskfile  record  nuaber. 

COMMON  /MENDAT  /  MENS1Z.  MENLIN.  HLPSIZ,  HLPLIN.  MLNSZ,  HLNSZ. 

1  MENVAL,  ACTHEN 

The  following  coaaon  block  contains  inforaation  that  pertains  to 

the  solution  to  the  current  problea. 

W  --  This  4  eleaent  array  contains  the  weights  or  constraint 
liaits  (depending  on  solution  technique). 

UB  —  This  4  eleaent  array  contains  the  upper  liait  for  the 
corresponding  objective  weights  or  constraint  liait. 

LB  —  This  4  eleaent  array  contains  the  lower  liait  fGr  the 
corresponding  objective  weights  or  constraint  liait. 

DEL  —  This  4  eleaent  arrav  conti ans  the  increaent  <  or  delta  ) 

that  is  to  be  used  in  going  froa  *  owe  liait  (LB)  to  the 
upper  liait. 

ISTRT  —  This  ites  identifies  the  solution  tvpe 

1  -  weighting  technique 

2  =  constraint  technique 

P  --  This  arrav  contains  the  aggregate  objective  coefficients 
as  used  by  the  LP  routine. 

D  —  This  array  contains  the  constraint  coefficients  as  used  bv 
the  LP  routine. 

IBV  —  This  arrav  is  return  troa  the  LP  routine  conatamina  the 
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C  identity  of  the  basic  variables  in  the  solution. 

C 

C  SOLNHT —  This  array  serves  as  a  storage  area  for  the  objective 
C  function  weights  that  correspond  to  each  solution. 

C 

C  VARNUH —  This  array  contains  the  variable  nusbers  for  each  basic 
C  variable  in  the  corresponding  solution. 

C 

C  VARVAL —  This  array  is  parallel  to  the  array  VARNUH  and  contains  the 
C  corresponding  basic  variable  values  for  each  solution. 

C 

C  OBJVAL —  This  array  contains  the  objective  function  values  for  the 
C  corresponding  solution. 

C 

C  ZF  --  This  array  contains  the  objective  values  for  the  current 
C  solution.  Once  the  current  solution  is  deterained  to  be  a 

C  NON-DOM I NATED  solution,  then  ZF  is  aoved  to  OBJVAL, 

C 

C  NNDS  —  This  i tea  contains  the  nuaber  of  N0N-B0M1NATED  solutions 
C  that  were  found. 

C 

C  CNXREF —  This  array  contains  pointers  to  the  constraint  arrays  in 
C  /  CON  /  that  are  used  to  relate  thea  to  the  constraint  data 

C  that  is  passed  to  the  LP  routine. 

C 

C  SPCFLG--  This  itea  is  used  to  signal  the  occurance  of  soae  special 
C  condition  for  the  current  problea.  A  value  of  0  is  default. 

C  «sans  an  infeasible  solution  has  been  detected.  -2  eeans 

C  that  art  unbounded  solution  has  been  detected. 

C 

l  UBWHT  --  This  array  is  used  only  if  an  unbounded  solution  is  detected 
C  then,  it  contains  the  objective  weights  that  were  in  use 

C  when  the  solution  was  found. 

C 

C  1CAP  —  This  ite*  assuaes  a  non-zero  value  whenever  io re  than  30 
C  NQN-DOHINATED  solutions  to  a  problea  are  detected.  The 

C  proorai  is  only  capable  of  saving  30  solutions. 

C 

COMMON  /  SOLN  /  N,  UB.  LB,  DEL,  ISTRT,  P,  D.  IBV,  S0LNHT,  VARNUH. 

1  VARVAL,  OBJVAL.  ZF,  NNDS.  CNKREF,  SPCFLG,  U8NHT, 

2  ICAP 
EQUIVALENCE  (  FNAME,  TEHP(l)  ) 

DATA  ACTMEN,  TEMPI  1)  /  -1  ,  X’2F’  / 

C 

C  Open  the  lenu/help  file.., NOTE:  it  aust  be  in  drive  2! 

C 

CALL  OPEN  (  7,  ’HENDAT  DAT’,  1  ) 

C 

C  Clear  the  screen  and  then  present  soae  introductory  inforaation 
C  then,  wait  for  the  user  to  hit  a  return  to  continue. 


WRITE  (  5,  900  ) 

CALL  PRSHEN  (  2,  0  ) 

CALL  PRSHEN  (  9.  0  ) 

CALL  6ETTXT  I  15.  0,  32,  0.  TXTVAL.  1  ) 

20  CONTINUE 
C 

C  clear  the  screen 
C 

WRITE  (  5.  900  ) 

C 

C  deter sine  if  there  is  an  active  probiea  file.  NOTE:  a  slash  </ >  in 
C  character  position  1  is  the  indication  that  no  probiea  is  active. 
C 

IF  (  TEMP <1 )  .NE.  X’2F’  )  60  TO  30 
C 

C  in  this  case,  no  proble*  is  active,  before  the  user  can  solve  a 
C  probiea  he  aust  activate  one.  Ask  his  hop  he  wishes  to  do  this. 

C  1  =  ioad  fros  disk 

C  2  =  define  a  new  probiea 

C  0  =  exit  prograa 

C 

CALL  6ETINT  (  24,  0.  2,  0,  INTVAL  > 

60  TO  (  100,  200  ),  INTVAL 
60  TO  9000 
30  CONTINUE 
C 

C  in  this  case,  a  proble*  exists,  ask  the  user  Hhat  he  wants  to  do, 

C  1  =  load  a  different  probiea  fros  disk 

C  2  -  define  a  new  probiea 

C  3  =  EDIT  the  currently  active  proble* 

C  4  =  solve  the  currently  active  proble* 

C  0  =  EXIT  the  progra* 

C 

CALL  6ETINT  <  30,  0,  4,  0,  INTVAL  ) 

GO  TO  (  100,  200,  300,  500  ),  INTVAL 
GO  TO  9000 
100  CONTINUE 
C 

C  —  Process  load  a  probiea  fros  disk  — 

C 

CALL  DSKPRB 
GO  TO  20 
200  CONTINUE 
C 

C  ---  Process  define  a  new  probiea  — 

C 

CALL  NEWPRB 
GO  TO  20 
300  CONTINUE 


253  C  —  Process  EDIT  current  problea  — 

254  C 

255  CALL  EDTPRB 

256  60  TO  20 

257  500  CONTINUE 

258  C 

259  C  —  Process  solve  the  current  problea  — 

260  C 

261  CALL  PRBSLV 

262  60  TO  20 

263  900  FORMAT (1H1) 

264  9000  CONTINUE 

265  WRITE  (  5,  900  ) 

266  CALL  PRSMEN  (  18,  0  > 

267  9999  CONTINUE 

268  STOP 

269  END 


Prograa  Unit  Length=00F5  (245)  Bytes 
Data  Area  Length=0048  (72)  Bytes 

Subroutines  Referenced: 


UNIT 

OPEN 

$M2 

$ND 

PRSMEN 

6ETT.TT 

6ETINT 

IC6 

DSKPRB 

NEWPRB 

EDTPRB 

PRBSLV 

»ST 


Variables: 


ACTMEN 

/HENDAT/+031C 

IBV 

/S0LN/+0592 

TXTVAL 

0001' 

MENVAL 

/HENDAT/+001C 

TEMP 

/PR0B/+02D9 

SPCFLS 

/S0LN/+0F5E 

VARNUM 

/S0LN/+0786 

CNXREF 

/S0LN/+0F54 

CTYPE 

/PROB/+01EO 

OTYPE 

/PR0B/+02D2 

NCON 

/PR0B/+02D6 

NOBJ 

/PR0B/+02D7 

NVAR 

/PR0B/+O2D8 

MENSIZ 

/HENDAT/+0000 

MENLIN 

/HENDAT/+0001 

HLPSIZ 

/MENDAT/+0002 

HLPLIN 

/HENDAT/+0003 

HLNSZ 

/HENDAT/+0004 

HLNSZ 

/HENDAT/+0010 

ZF 

/S0LN/+0F42 

OBJVAL 

/S0LN/+0D62 

VARVAL 

/S0LN/+08B2 

SQLWHT 

/S0LN/+05A6 

UBWHT 

/S0LN/+0F5F 

N 

/S0LN/+0000 

UB 

/SOLN/tOOlO 

LB 

/S0LN/+0020 

DEL 

/S0LN/+0030 

P 

/S0LN/HI042 

D 

/SOLN/+OOBA 

CON 

/PR08/+0000 

OBJ 

/PROS/ +0212 

RHS 

/PR0B/+01EA 

CNAME 

/PR0B/+0190 

ONAME 

/PR0B/+-02B2 

FNAME 

/PR0B/+02D9 

1STRT 

/S0LN/+0040 

NNDS 

/S0LN/+0F52 

ICAP 

/S0LN/+0F6F 

H; 0001 

0021' 

T : 000002  0034' 

INTVAL 

0035* 

COMMON  Length 

/PR08/02E1  (737) 
/HENDAT/031E  (798) 
/30LN/0F71  (3953) 


PRBSLV 


Problem  Solve 


Processing  Description.  PRBSLV  is  the  first  level  of 
the  problem  solving  function.  It  is  called  when  the  user 
indicates  he  wants  to  solve  a  problem. 

The  first  activity  of  PRBSLV  is  to  determine  which  pro¬ 
cessing  option  (i.e.j,  constraint  or  weighting)  is  desired. 
If  the  user  requests  the  weighting  technique,  PRBSLV  offers 
two  options;  using  specific  weights  or  a  range  of  weights. 
For  the  specific  weight  option,  the  user  is  prompted  for  a 
weight  for  each  objective.  PRBSLV  does  not  require  these 
weights  to  sum  to  one.  For  the  range  of  weights  option,  the 
user  selects  a  weight  increment  from  a  pre— determi ned  set. 
This  increment  will  be  used  for  determining  objective 
weights  as  the  problem  is  solved. 

If  the  user  requests  the  constraint  technique,  PRBSLV 
will  prompt  the  user  for  upper  bound,  lower  bound  and  incre¬ 
ment  for  all  but  the  first  constraint. 

Once  these  solution  parameters  are  determined,  PRBSLV 
calls  SOLVE  to  continue  solution  processing. 

Key  Local  Variables 

ITER  —  This  variable  is  set  to  the  number  of  iterations 
that  the  solution  will  require  as  defined  by  the 
user.  For  the  weighting  technique,  ITER  is  a 
function  of  weight  increment  and  the  number  of 
objectives.  For  the  constraint  technique,  ITER  is  a 
function  of  the  constraint  increment  and  the  number 
of  objectives. 


Module  Listing.  The  following 
FORTRAN  compilation  listing  for  PRBSLV 


pages  contain  the 


FORTRAN-30  Ver.  3.43  Copyright  1978-1981  (C)  Bv  Microsoft  --  Bytes.'  25131 
Created:  27-Jun-81 

1  SUBROUTINE  PRBSLV 

2  C 

3  C  Subroutine  PRBSLV  --  Problei  solve 

4  C 

5  C  This  subroutine  is  the  first  level  of  the  software  designed  to  solve 

6  C  probleas.  Its  purpose  is  to  deteriine  which  solution  technique 

7  C  (  weighting  or  constraint  )  the  user  desires,  and  then  interagate  the 

8  C  user  for  the  information  needed  to  carrv  out  the  solution.  After 

9  C  this,  PRBSLV  calls  the  appropriate  solution  routine  for  further 

10  C  processino. 

11  C 

12  C  PRBSLV  uses  no  calling  paraaeters. 

13  C 

14  REAL  INC (7),  P(30),  D(10,31),  SOLWHT ( 30, 4> ,  UBWHT(4) 

15  REAL  ZF(4),  0BJVAL<30,4) ,  VARVAL (30, 10) 

16  REAL  W<4),  U8(4>,  LB<4),  DEL (4),  CON(IO.IO),  0BJ14.10),  RHSilO) 

17  REAL*8  CNANEilO),  0NAME14).  FRAME 

18  INTEBER  IBV(IO),  ITS128) 

19  INTEBER*1  SPCFLG,  VARNUH (30, 10) ,  CNXREFUO) 

20  INTEGERS  CTYPE(IO),  0TYPE(4),  NCON.  NOBJ,  NVAR 

21  COMMON  /  PROS  /  CON,  CNANE,  CTYPE,  RHS,  OBJ,  ONAME.  OTYPE,  NCON, 

22  1  NOBJ,  NVAR,  FNAHE 

23  COMMON  /  SOLN  /  N,  UB,  LB,  BEL,  ISTRT,  P,  D,  IBV,  SOLHHT,  VARNUM, 

24  1  VARVAL.  OBJVAL,  ZF,  NNDS.  CNXREF,  SPCFLG,  UBWHT, 

25  2  ICAP 

28  DATA  INC(l) ,  INC(2),  INCI3),  INC(4),  INCiS),  INCI6),  INC17)  / 

27  1  1.000,  0.500,  0.333,  0.250.  0.200,  0.100,  0.050  / 

28  DATA  ITS ( 1 > .  ITSI2),  ITS<3>,  ITS<4>,  ITS<5).  ITSI6).  ITS<7)  / 

29  1  1,  2,  3,  4,  I,  3.  6  / 

30  DATA  ITS(8),  ITS(9),  ITSUO),  ITS(ll),  ITS(12),  ITSI13),  ITS(14)  / 

31  1  10,  1,  4,  10,  20,  1,  5  / 

32  DATA  ITS(15),ITS(16),ITSU7),  ITS(18),  ITSI19),  ITSI20),  ITS(21)  / 

33  1  15,  35,  1,  6.  21,  56.  1  / 

34  DATA  ITS(22) , ITS423) , 1TS(24) ,  ITS(25),  ITS(26),  ITS!27),  ITS(28)  / 

35  1  11,  66,  286,  l,  21.  231,  621  / 

36  C 

37  C  sake  correction  for  1NC(3>,  that  is,  get  all  significant  digits. 

38  C 

39  ICAP  =  0 

40  NNDS  =  0 

41  SPCFLB  =  0 

42  INC (3)  =  1.0  /  3.0 

43  10  CONTINUE 

44  C 

45  C  clear  the  screen 

46  C 

47  WRITE  (  5.  9000  ) 

48  15  CONTINUE 

49 


C 


50 

c 

call  8ETINT  to  deteraine  which  solution  technique  the  user  desires 

51 

c 

1  =  weighting 

52 

c 

2  =  constraint 

53 

c 

0  =  EXIT 

54 

c 

55 

CALL  GET1NT  (  166.  0.  2.  0,  ISTRT  ) 

56 

60  TO  (  20,  1000  ),  ISTRT 

57 

60  TO  9999 

58 

20  CONTINUE 

59 

c 

40 

c 

— this  section  of  code  processes  the  weighting  technique. 

41 

c 

62 

c 

clear  the  screen 

63 

c 

64 

WRITE  (  5,  9000  ) 

65 

c 

66 

c 

present  general  lessage  about  the  weighting  technique,  then  ask  the 

67 

c 

user  which  of  the  tno  available  options  he  Hants. 

68 

c 

1  =  Height  wi th  specific  Heights 

69 

c 

2  =  Height  with  a  range  of  Heights  on  all  objectives 

70 

c 

0  =  EXIT  Height  technique 

71 

c 

72 

CALL  PRSMEN  (  172,  0  ) 

73 

CALL  GETINT  (  183,  0,  2,  0,  INTVAL  ) 

74 

60  TO  (  50.  500  1,  INTVAL 

75 

GO  TO  10 

74 

c 

77 

c 

enter  loop  to  ask  user  for  the  Height  on  each  objective.  NOTE:  the 

78 

c 

Heights  need  not  sua  to  one! 

79 

c 

80 

50  CONTINUE 

81 

DO  100  1=1,  NOBJ 

82 

WRITE  (  5,  9001  )  I,  0NAHEII1 

83 

CALL  GETFLT  (  189,  1,  1.0,  0.0,  Nil)  ) 

84 

100  CONTINUE 

85 

c 

86 

c 

call  NSQLVE  to  process  the  neighting  technique  solution 

87 

c 

83 

CALL  NSOLVE 

89 

GO  TO  2000 

90 

500  CONTINUE 

91 

C 

92 

C 

call  GETINT  to  get  the  Height  increaent  that  the  user  Hants 

93 

C 

1=1.0;  2=0.5:  3=0.333i  4=0.25!  5=0.2!  6=0.1;  7=0.05 

94 

C 

0  =  EXIT  the  neighting  technique 

95 

C 

96 

CALL  6ETINT  (  178,  0,  7,  0,  INTVAL  ) 

97 

IF  (  INTVAL  ,EQ.  0  1  GO  TO  20 

98 

ITER  =  1  (  INTVAL  -11*41+  N08J 

99 

ITER  =  ITSUTER) 

100 

C 

204 


C  set  CEL  equal  to  the  increaent 
C 

DO  510  1=1,  NOBJ 
DEL(I)  =  INC ( INTVAL) 

510  CONTINUE 
C 

C  set  upper  and  lower  bound  1 iaits  for  each  of  the  objective  weights 
C 

DO  520  1  =  1.  NOBJ 
UB(I)  =  1.000 
LB<I)  =  0.000 
520  CONTINUE 
GO  TO  1030 
1000  CONTINUE 
C 

C  — this  section  processes  the  constraint  technique  requests 
C 

IF  (  NOBJ  ,NE.  1  )  GO  TO  1010 
CALL  CSOLVE 
GO  TO  2000 
1010  CONTINUE 
C 

C  clear  the  screen 
C 

WRITE  (  5.  9000  ) 

ITER  =  (  NCON  +  (  NOBJ  -  1  1  )  -  10 
IF  (  ITER  ,LE.  0  )  GO  TO  1015 
WRITE  I  5,  9004  )  ITER 
GO  TO  15 
1015  CONTINUE 
C 

C  present  a  general  blurb  telling  what  the  constraint  technique  is  all 
C  about 
C 

CALL  PRSMEN  (  194.  0  ) 

WRITE  (  5.  9002  1  ONANE(l) 

C 

C  enter  loop  to  get  the  upper  bound,  lower  bound,  and  increaent  for 
C  each  of  the  objectives  that  are  to  be  processed  as  constraints. 

C 

ITER  =  1 

IF  (  NOBJ  ,E8.  1  )  GO  TO  1030 

DO  1020  1  =  2.  NOBJ 

WRITE  I  5,  9003  )  I,  ONAHE(l) 

CALL  GETFLT  (  200,  0,  99999.0,  -99999.0,  UB(I)  ) 

CALL  GETFLT  (  205,  0,  UB(I),  -99999.0,  LB ( I >  ) 

CALL  GET1NT  (  210,  0,  50,  1,  INTVAL  ) 

C 

C  calculate  the  delta  (DEL)  for  the  constraint  liait  incresent. 

C 


DEL (I)  =  (UB  < I ) -LB  < I ) ) /INTVAL 


152 

ITER  =  ITER  i 

>  (  INTVAL  *  1  ) 

153 

WRITE  (  ! 

5,  9000  ) 

154 

1020  CONTINUE 

155 

1030  CONTINUE 

156 

C 

157 

C  call  SOLVE  1 

to  continue  solution  processing  --  NOTE:  this  call  ii 

153 

C  aade  for 

both  the  weighting  and  constraint  techniques. 

159 

C 

160 

CALL  SOLVE  ( 

ITER  ) 

161 

2000  CONTINUE 

162 

CALL  PRTANS 

163 

9000  FORMAT  ( 

1H1 

) 

164 

9001  FORMAT  ( 

1H  , 

’Please  specify  the  weight  for  objective’,  11, 

165 

1 

}  a  J 

I 

,  A8,  /  > 

166 

9002  FORMAT  ( 

1H  , 

’Gbjectivel:  A9,  ’  will  be  optiaized.',  /  > 

167 

9003  FORMAT  ( 

1H  , 

’—OBJECTIVE’.  11,’:  ’,A8,’ — ’) 

163 

9004  FORMAT  ( 

1H  , 

’**♦*  TOO  MANY  CONSTRAINTS  FOR  THE  CONSTRAINT  1 

169 

1 

’TECHNIQUE  *♦**’,  /,  ’  ’,  ’Please  redefine  the 

170 

2 

’problea,  deleting’,  12,  ’  of  thea,  or  use  the 

171 

3 

’weighting  technique’,  /  ) 

172 

9999  CONTINUE 

173 

RETURN 

174 

END 

Prograa  Unit  Length=0389  (905)  Bytes 
Data  Area  Length=0lD2  66)  Bytes 

Subroutines  Referenced: 

*13 

*DB 
$ND 

PRSHEN 
CSQLVE 
*NB 

PRTANS 


Variables: 

INC 

0001’ 

P 

/S0LN/+0042 

D 

/SOLN/+OOBA 

SOLWHT 

/S0LN/+05A6 

UBNHT 

/S0LN/«-0F5F 

ZF 

/SQLN/+0F42 

OBJVAL 

/S0LN/+0D62 

VARVAL 

/S0LN/+08B2 

H 

/S0LN/+0000 

UB 

/S0LN/+Q010 

LB 

/SQLN/*0020 

DEL 

/S0LN/+0030 

CON 

/PR0B/+0000 

OBJ 

/PR0B/+0212 

RHS 

/PR0B/+01EA 

CNAME 

/PR0B/+0190 

ONAME 

/PR08/+-02B2 

FNAME 

/PR0B/+02D9 

IBV 

/S0LN/+0592 

ITS 

00  ID" 

SPCFLS 

/S0LN/+OF5E 

VARNUM 

/S0LM/+0786 

CNXREF 

/S0LN/+0F54 

CTYPE 

/PR0B/+01E0 

OTYF'E 

/PR0B/+02D2 

NCON 

/PR0B/+02D6 

NOBJ 

/PR0B/+02D7 

NVAR 

7PR08/+02D3 

ISTRT 

/ S0LH/+0040 

NNDS 

/SOLN/+OF52 

ICAP 

/S0LN/+0F6F 

INTVAL 

005B* 

I 

0063" 

T: 000000  0065* 

T:  000002  0073* 

ITER 

0074“ 

*10 

*L1 

♦T1 

*H2 

SET  I  NT 

*CS 

GETFLT 

NSOLVE 

*SB 

*DA 

*H9 

SOLVE 

T: 010000 


0076’  T1020000 


0078 


COMMON  Length 

/PRGB/02E1  (737) 
/SQLN/0F7 1  (3953) 


Labels: 


10L 

0022’ 

9000L 

008C 

15L 

002E’ 

20L 

0048’ 

1000L 

01  A3’ 

9999L 

0338’ 

50L 

0077’ 

500L 

00E5’ 

100L 

OOCB’ 

900 1L 

0091* 

2000L 

0335’ 

510L 

0146’ 

520L 

0191 

1030L 

032F’ 

101 OL 

01BC’ 

101SL 

0204’ 

9004L 

0127" 

9002L 

OOCF“ 

1020L 

0314’ 

9003L 

0100* 

PROANS 


Process  Answer 


Processing  Description.  This  routine  is  called  -fol¬ 
lowing  each  linear  programming  iteration.  Its  purpose  is  to 
examine  the  solution  and  determine  if  it  belongs  in  the  non— 
dominated  solution  set.  If  so,  the  current  solution  is 
added . 

First,  PROANS  checks  for  the  special  cases.  Infeasible 
solutions  are  ignored.  If  the  solution  is  unbounded  and  it 
is  the  first  unbounded  solution  found,  PROANS  sets  SPCFLG  to 
one  and  stores  the  weight  values  that  were  in  effect  for  the 
sol  ut  i  on. 

At  this  point,  PROANS  computes  the  objective  values  for 
each  of  the  problem  objectives.  The  objective  values  are 
used  to  determine  if  the  new  solution  should  be  included  as 
part  of  the  non-domi nated  solution  set.  To  determine 
dominance,  the  new  solution  is  compared  with  each  solution 
that  is  already  in  the  NDSS.  If  some  non— domi nated  solution 
(NDS)  has  all  of  its  objective  values  greater  than  the  new¬ 
est  solution’s  objectives,  then  the  new  solution  is  dominat¬ 
ed  and  can  be  rejected  without  examining  the  rest  of  the 
NDSS. 

If  all  of  the  new  solution’s  objectives  exceed  all  of 
the  objectives  for  one  or  more  of  the  elements  in  the  NDSS, 
then  these  elements  are  dominated  and  must  be  rejected  and 
the  new  solution  accepted.  If  the  new  solution  has  a  higher 
value  for  at  least  one  of  the  objectives  than  all  of  the 
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other  solutions,  then  it  is  a  NDS  and  it  is  added  to  the 


NDSS. 


Key  Local  Variables. 

ZF  —  This  array  contains  the  objective  values  -for  the  new 
solution. 

IC1  —  The  number  o-f  the  current  solution  objectives  that 
are  less  than  the  present  NDS. 

IC2  —  The  number  of  the  current  solution  objectives  that 
are  greater  than  the  present  NDS. 

IC3  —  The  number  of  the  current  solution  objectives  that 
are  equal  to  or  less  than  the  present  NDS. 

Module  Listing.  The  following  pages  contain  the 


FORTRAN  compilation  listing  for  PROANS. 


FQRTRAN-80  Ver.  3.43  Copyright  1978*1981  (C)  Bv  Microsoft  —  Bvtes.‘  25131 
Created:  27- Jun-81 

1  SUBROUTINE  PROANS  (  12.  Vi  1 

2  C 

3  C  Subroutine  PROANS  —  Process  answer 

4  C 

5  C  This  subroutine  is  called  after  each  linear  progressing  iteration. 

6  C  Its  purpose  is  to  examine  the  current  solution  and  detersine  if  it 

7  C  should  be  retained  as  a  NGH-DGHINATEB  solution.  The  routine  works 

8  C  by  cosoaring  objective  values  of  the  current  solution  with  all  of  the 

9  C  NGN-DOMINATED  solutions  alreadv  found.  If  the  nea  solution  is 

10  C  dominated  by  one  or  sore  of  the  NO  solutions,  it  is  rejected.  If  it 

11  C  dosinates  any  ND  solution  than  the  dominated  solution  is  throan  out. 

12  C 

13  C  Calling  parameters  *— 

14  C 

15  C  12  --  The  nusber  of  coiusns  in  the  solution  matrix  -D-  as  generated 

16  C  bv  LP.  NOTE  that  this  includes  a  column  for  the  right  hand 

17  C  side.  In  fact,  DiK.IZ)  contains  the  basic  variable  solution 

IS  C  values  for  K  =  1  to  NCON  (+N08J-1  for  constraint  tech). 

19  C  IN  --  Is  the  LP  return  code,  and  is  used  only  if  LP  detected  a 

20  C  "funny"  result  such  as  infeasible  (  =  - 1  )  or  unbounded  !  =  *2) 

21  C 

22  REAL  N<4>,  U8(4),  LB(4),  DEL(4),  ZF14),  OBJVAL (30, 4) ,  P130), 

23  1  VARVAL (30, 10) ,  DUO, 31),  CQNU0.10),  0BJ(4,10),  RHStlO) 

24  REAL  SQLNHT (30,4) ,  U8NHT (4) 

25  REALt8  CNAKEUO),  0NANEI4) ,  FNAME 

26  INTESER  IBVU0),  ISTRT,  NNDS 

27  INTESERM  SPCFLB,  VARNUM (30, 10) ,  CNXREF(IO) ,  IC1,  IC2,  IC3, 

28  1  CTYPEU0),  0TYPE14),  NCON,  NQBJ,  NVAR,  NCDNX 

29  COMMON  /  PROB  /  CON,  CNAME,  CTYPE,  RHS,  OBJ,  ONAME,  OTYPE.  NCON. 

30  1  N0BJ,  NVAR,  FNAHE 

31  COMMON  /  SOLN  /  H,  UB,  LB,  DEL.  ISTRT,  P,  D,  I8V,  SOLWHT,  VARNUM. 

32  1  VARVAL,  OBJVAL,  ZF.  NNDS,  CNXREF,  SPCFLS,  UBNHT. 

33  2  I  CAP 

34  C 

35  C  Compute  the  number  of  basic  variables.  Recall,  that  this  is  equal  to 

36  C  the  number  of  constraints.  The  nusber  of  constraints  is  NCON,  but 

37  C  for  the  constraint  technique  (  ISTRT  =  2  )  there  are  NQBJ  -  1  extra 

33  C  constraints. 

39  C 

40  NC-ONX  =  NCON  +  (  ISTRT  -  1  )  »  (  NOBJ  *  I  ) 

41  C 

42  C  Check  for  an  infeasible  solution.  If  found,  ignore  this  solution. 

43  C 

44  IF  (  IN  .Efl.  (-2)  )  GO  TO  999 

45  C 

46  C  Check  for  an  unbounded  solution.  If  found,  check  to  see  if  it  is  the 

47  C  first  one.  If  it  is  the  first,  retain  the  weights  that  were  used 

48  C  in  getting  it.  If  not  the  first,  ignore  it.  The  goal  here  is  to 

49  C  let  the  user  know  that  at  least  one  unbounded  occurred  and  wnat 


I 


i 


I 


« 


50  C  weights  were  used  to  get  it. 

51  C 

52  IF  (  li  .NE.  (-1)  )  60  TO  50 

53  IF  (  SPCFL6  .NE.  0  )  GO  TO  999 

54  SPCFL6  =  1 

55  DO  40  I  =  1,  N08J 

54  UBHHT(I)  =  HU! 

57  40  CONTINUE 

58  GO  TO  999 

59  50  CONTINUE 

40  C 

41  C  Enter  loop  to  coapute  the  objective  values  for  the  current  solution. 

42  C  Do  this  for  each  objective,  and  store  the  values  in  ZF(object). 

63  C 

44  DO  200  1=1.  NOBJ 

65  ZF(I)  =  0.0 

66  DO  100  J  =  1,  NCONX 

67  IF  <  IBV(J)  .GT,  NVAR  )  GO  TO  100 

68  IC1  =  IBV(J) 

69  ZFU)  =  ZFII)  +  (  OBJ(l.ICl)  *  DfJ.IZ!  ! 

70  100  CONTINUE 

71  200  CONTINUE 

72  C 

73  C  Check  to  see  if  any  NON-DGHINATED  solutions  (NNDS)  have  yet  been 

74  C  found. 

75  C 

76  IF  (  NNDS  .EQ.  0  )  60  TO  600 

77  C 

78  C  Enter  loop  to  coapare  the  current  solution  with  each  of  the  NGN- 

79  C  DOMINATED  solutions  already  found. 

BO  C 

81  DO  500  1=1,  NNDS 

82  230  CONTINUE 

83  IC1  =  0 

84  IC2  =  0 

85  IC3  =  0 

86  C 

87  C  Enter  loop  to  coapute! 

88  C  IC1  -->  The  nuiber  of  the  current  solution  objectives  that  are 

89  C  less  than  the  present  NNDS. 

90  C  IC2  -->  The  nuaber  of  the  current  solution  objectives  that  are 

91  C  equal  to  or  greater  than  the  present  NNDS. 

92  C  IC3  -->  The  nuaber  of  the  current  solution  objectives  that  are 

93  C  equal  to  or  less  than  the  present  NNDS. 

94  C 

95  DO  250  J  =  1,  NOBJ 

96  AX  =  OBJVALU, J)  -  0.01 

97  AV  =  OBJVALU, J)  +  0.01 

98  IF  (  (  ZF(J)  .LE.  AX  .AND.  OTYPE(J)  .NE,  2  )  .OR. 

99  1  (  ZF(J)  .SE.  AY  .AND.  OTYPE(J)  -EQ.  2  )  !  IC1  =  IC1  +  1 

100  IF  (  (  ZFU)  .GT.  AX  .AND.  OTYPEU!  .NE.  2  )  .OR. 


1  (  ZF(J)  .LT.  AY  .AND.  OTYPE(J)  .EB.  2  )  )  IC2  =  IC2  ♦  1 

IF  (  (  ZF(J)  .LT.  AY  .AND.  OTYPE(J)  .NE,  2  )  .QR. 

1  (  ZF!J)  .6T.  AY  .AND.  OTYPE(J)  .EB.  2  )  )  IC3  =  IC3  +  1 

250  CONTINUE 
C 

C  If  all  current  objectives  are  less,  than  the  current  solution  is 
C  dominated  and  should  be  rejected. 

C 

IF  (  IC1  .EB.  NOBJ  )  GO  TO  999 
C 

C  Check  if  not  all  of  the  current  objectives  exceed  the  present  NNDS. 

C  If  this  condition  exists  then  so  far,  this  is  a  new  NNDS  and  we 

C  aust  continue  checking  the  others  before  ruling  this  one  out. 

C 

IF  !  IC2  .NE.  NOBJ  )  GO  TO  500 
C 

c  If  IC3  does  not  equal  NOBJ  and  IC2  eouals  NOBJ  then  the  current 
C  solution  doainates  the  present  NDSS  and  the  present  NDSS  should  be 
C  thrown  out. 

C 

IF  IC3.  NE.  NOBJ  )  GO  TO  400 
C 

C  The  following  code  is  executed  oaly  for  the  case  when  all  objectives 
C  of  the  current  solution  aatch  the  present  NNDS.  If  the  basic 

C  variables  are  different  then  the  solution  aust  be  retained  other- 

C  wise  we  can  throw  it  out. 

C 

\Z7  --  0 
C 

C  Enter  loop  to  coapare  the  x’s. 

C 

DO  300  J  =  1.  NCONY 
AY  =  ABS  (  VARVAL ( I , J )  ) 

IF  (  AY  ,GE.  0.001  )  GO  TO  270 
IC2  =  IC2  t  1 
GO  TO  300 
270  CONTINUE 

DO  290  K  =  1,  NCONY 

IF  (  IBV(K)  .NE.  VARNUMd, J)  )  60  TO  290 
AY  =  ABS  (  VARVAL ( I. J)  -  DiK.IZ!  1 
IF  (  AY  ,LE.  0.01  )  IC2  =  IC2  +  I 
GO  TO  300 
290  CONTINUE 
300  CONTINUE 
C 

C  If  all  the  x’s  aatched  then  we  threw  out  the  present  NNDS  and  retain 
C  the  current  solution.  If  all  the  Y’s  did  not  aatch  then  we  keep 
C  both. 

C 

IF  (  IC2  .NE.  NCONY  )  GO  TO  500 
400  CONTINUE 


c 

C  NOTE:  If  the  solution  we  intend  to  throw  out  is  the  last  one.  then 
C  there  is  no  need  to  tonally  uppack  the  arrays. 

C 

IF  (  I  .Efi.  NNDS  )  60  TO  460 
IC3  =1+1 
C 

C  Enter  looo  to  delete  an  existing  NNDS  by  unpacking  the  NNDS  arrays. 

C 

DO  450  J  =  ICS.  NNDS 
IC2  =  J  -  1 
DO  430  K  =  1.  NOBJ 
OBJVAL ( IC2, K)  =  OBJVAL(J.K) 

S0LNHT(IC2,K)  =  SOLWHT (J.K) 

430  CONTINUE 

DO  440  K  -  1,  NCONX 
VARNUN(IC2,K)  =  VARNUHiJ.K) 

VARVAL ( IC2 . K)  =  VARVALiJ.iO 
440  CONTINUE 
450  CONTINUE 
460  CONTINUE 

NNDS  =  NNDS  -  1 
C 

C  Since  we  have  just  uppacked  the  arrays,  if  we  don’t  wake  the  follow- 
C  ing  cneck,  one  NNDS  will  'sneak'  by  without  being  checked.  So  here 
C  I  juao  back  within  the  loop.  NOTE:  That  the  loop  variable  I 

C  doesn’t  increwent.  instead  the  loop  liwit  (  NNDS  >  has  been  de- 

C  resented. 

C 

IF  (  I  ,LE.  NNDS  )  60  TO  230 
500  CONTINUE 
C 

C  At  this  point,  we  have  deteriinefl  that  the  current  solution  should  be 
C  retained  as  an  NNDS.  If  we  already  have  the  liwit  of  30.  set  the 

C  capacity  flag  IICAPI,  otherwise,  add  the  solution, 

C 

IF  (  NNDS  NE.  30  )  60  TO  600 
ICAP  =  1 
60  TO  999 
600  CONTINUE 

NNDS  =  NNDS  +  1 
DO  700  1=1.  NO&J 
OBJUAL(MMDS.I)  =  IF (I) 

SOLNHT(NNDS.I)  =  14(1) 

700  CONTINUE 

CO  800  1  =  1.  NCONX 
UARVAKNNDS.H  =  DU. ID 
VARNUNINNDS.il  =  IBV(I) 

Rf"  Continue 
999  continue 


.  m ^  ^  ^  ^  ..  t  .  •  .  w-„  •  ,  *■  w  ..*•  .*■  r 


203  END 

Prograa  Unit  Lenath=0776  (1910)  Bytes 
Data  Area  Length=002D  (451  Bvtes 

Subroutines  Referenced: 


ABS 

*M9 

*L1 

*11 

4MB 

IAB 

*MA 

m 

*SB 

Variables: 

IZ 

0001* 

IN 

0003* 

H 

/S0LN/+0000 

UB 

/80LN/+0010 

LB 

/SQLN/+0020 

DEL 

/S0LN/+0030 

ZF 

/SQLH/+0F42 

D8JVAL 

/S0LH/+0D62 

P 

/  SOLH  /  +-0042 

VARVAL 

/8QLN/+0882 

D 

/S0LN/+00BA 

CON 

/PROS/ +0000 

OBJ 

/PR0S/+0212 

RHS 

/PR0B/+O1EA 

SOLWHT 

/S0LN/+05A6 

UBWHT 

/S0LN/+0F5F 

CNAME 

/PR08/+0190 

□NAME 

/PR0B/+02B2 

FNAHE 

/PR0B/+02D9 

IBV 

/SQLN/+0592 

ISTRT 

/S0LN/+0040 

HMDS 

/SQLN/+0F52 

SPCFLS 

/S0LN/+0F5E 

VARNUM 

/S0LN/+O786 

CHXSEF 

/S0LN/+0F54 

1C1 

0005* 

IC2 

0006* 

IC3 

0007* 

CTYPE 

/PR0B/+01E0 

OTYPE 

/PRQB/+Q2D2 

NCQN 

/PRQ8/+02D6 

NOBJ 

/PR0B/+02D7 

NVAR 

/PR0B/+02D3 

NCQNX 

0003* 

ICAP 

/SDLN/+0F6F 

1:000002 

0009 

T: 010002  000 A’ 

I 

0008* 

T:  000000 

OOOD' 

T;  010000  OOOF* 

J 

ooir 

1:020000 

0013' 

T.030000  0015* 

A* 

0017* 

AY 

001B* 

T: 020002  001F" 

T 1030002  0020* 

K 

0021* 

T: 000001  0023* 

T: 040000  0027* 

1:050000 

0029' 

T: 060000  002B* 

COrtrlON 

Length 

/PR08/02E1  (737) 
/SQLN/0F71  (3953) 

labels: 

999L 

0769’ 

SOL 

00A9’ 

40L 

0092’ 

200L 

0176’ 

100L 

0162’ 

600L 

066B’ 

500L 

063B’ 

230L 

0143' 

250L 

0327’ 

4001 

048E’ 

300L 

0499’ 

270L 

03BC’ 

290L 

0485’ 

460L 

0616’ 

4  SOL 

0606’ 

430L 

055C’ 

440L 

05F2’ 

700L 

06C3’ 

BOOL 

0755’ 
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PROHLP  —  Process  Help 

I  Processing  Description.  This  module  is  called  whenever 

the  user  requests  help  by  entering  "HELP*1  or  It  is 

also  called  to  process  requests  -for  problem  displays  that 
are  initiated  by  entering  or  "©P".  It  PROHLP  is  being 

called  tor  a  HELP  request,  it  calls  PRSMEN  to  present  the 
help  information.  If  PROHLP  is  being  called  for  a  problem 

display  request,  it  calls  PRTPRB  to  present  the  problem 
di spl ay. 

Key  Local  Variables.  Refer  to  the  module  listing. 
Module  Listing.  The  following  pages  contain  the 


FORTRAN  compilation  listing  for  PROHLP 


FORTRAN-80  Ver.  3.43  Copyright  1978-1981  (Cl  By  Microsoft  --  Bytes:  25131 
Created:  27-Jun-8l 

1  SUBROUTINE  PROHLP  (  IHELP,  MENU ID  ) 

2  C 

3  C  Subroutine  PROHLP  --  Process  HELP 

4  C 

5  C  This  subroutine  is  called  by  SET1HT,  6ETFLT,  or  6ETTXT,  whenever  the 

6  C  user  inputs  ’?*,  'HELP'.  'S’,  or  "8P*  in  response  to  any  proeot. 

7  C  The  purpose  of  this  routine  is  to  process  the  special  request  ac- 

8  C  cordingly.  For  HELP  requests,  PRSMEN  is  called  to  print  the  HELP 

9  C  eessage.  For  problei  display  reouests,  PRTPRB  is  called. 

10  C 

11  C  paraaeter  descriptions: 

12  C 

13  C  IHELP  --  This  i tea  identifies  the  type  of  request  as  follows: 

14  C  1  =  HE1P  request 

15  C  2  =  Display  proble*  on  screen  request 

16  C  3  =  Print  proble*  request 

17  C  MENUID  --  This  i tea  gives  the  identity  of  the  *enu  for  which  HELP 

18  C  is  beino  requested. 

19  C 

20  C  Check  for  HELP  request 

21  C 

22  IF  (  IHELP  .HE.  1  )  60  TO  100 

23  CALL  PRSMEN  I  MENUID,  1  ) 

24  60  TO  999 

25  100  CONTINUE 

26  C 


27 

C  Check  for  Display  proble*  to  screen  request 

28 

C 

29 

IF  (  IHELP  .HE.  2 

60  TO  200 

30 

CALL  PRTPRB  (  5  ) 

31 

WRITE  (  5.  902  ) 

32 

READ  (  5.903  1  II 

33 

60  TO  800 

34 

200  CONTINUE 

35 

WRITE  (  5.  900  ) 

36 

WRITE  1  5,  902  ) 

37 

READ  (  5,  903  1  II 

38 

CALL  PRTPRB  (  2  ) 

39 

800  CONTINUE 

40 

WRITE  (  5,  901  ) 

41 

999  CONTINUE 

42 

900  FORMAT  (  1H1,  10X, 

•’»  TO  PRINT  THE  PROBLEM  «’,//, 

43 

1 

13X,  ’1.  Turn  on  the  printer’,  / 

44 

2 

131,  ’2.  Set  printer  on-line’,  / 

45 

3 

13X,  ’3.  Align  the  paper’  ) 

46 

901  FORMAT  (  1H1  ) 

47 

902  FORMAT  (  1H0,  ’»*♦  WHEN  READV  TO  CONTINUE,  PRESS  THE 

48  1  ’CARRIAGE  RETURN  ***’  I 

49  903  FORMAT  I  110  ) 


Prograa  Unit  Length=008E  (190)  Bytes 
Data  Area  Length=00E5  (229)  Bytes 

Subroutines  Referenced: 

$10  PRSHEN 

$H2  $ND 

Variables: 


PRTPRB 

$R2 


I HELP  0001 


MENU ID  0003 


T 1000002 


F'RSMEN  —  Present  Menu 

Processing  Description.  PRSMEN  is  called  to  present  a 
menu  or  help  information  to  the  user  on  the  video  display 
screen-  The  calling  program  must  identify  the  desired  menu 
or  help  information  by  supplying  its  starting  menu/help  file 
record  number  in  the  calling  sequence  (MENUID) . 

When  called,  PRSMEN  compares  MENUID  to  ACTMEN  to  deter 
mine  if  the  requested  data  is  already  in  the  MENDAT  common 
block.  If  it  is  not,  PRSMEN  must  read  the  menu/help  file  to 
load  it.  Once  the  data  is  contained  in  the  MENDAT  common 
block,  PRSMEN  prints  it  to  the  video  display  screen.  As 
specified  in  the  calling  sequence,  PRSMEN  will  output  either 
the  menu  or  the  help  data. 

Key  Local  Variables. 

1ST ART  -  Pointer  to  the  character  data  buffer  (MENVAL)  for 
the  starting  character  of  the  current  line. 

ISTOP  —  Pointer  to  the  character  data  buffer  (MENVAL)  for 
the  ending  character  of  the  current  line. 

Module  Listing.  The  following  pages  contain  the 
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FORTRAN-30  Ver.  3.43  Copyright  1978-1981  (0  By  MicrosoFt  --  Bytes:  25131 
Created:  27-Jun-81 

1  SUBROUTINE  PRSMEM  (  NENUID,  HELPFL  ) 

2  C 

3  C  Subroutine  PRSMEM  --  Present  aenu 

4  C 

5  C  This  subroutine  is  designed  to  retrieve  and  display  aenu  or  help 

6  C  inforaation  to  the  console  device.  Wien  called  PRSNEN  coaoares 

7  C  NENUID  (  which  indicates  which  aenu  is  desired  )  with  ACTNEN 

8  C  (  which  indicates  which  aenu  is  currently  active  ).  If  thev  are 

9  C  the  saae,  then  PRSNEN  displays  the  aenu  data  currently  stored  in 

10  C  the  coaaon  block  /HENDAT/.  If  they  are  different,  then  PRSNEN 

11  C  retrieves  the  appropriate  aenu  data  froa  the  aenu/help  file  on 

12  C  disk  (NENDAT.DAT  --  drive  2).  PRSNEN  will  display  either  aenu  or 

13  C  help  data  when  called,  deaending  on  the  value  of  HELPFL. 

14  C 

15  C  paraeeter  descriptions: 

16  C 

17  C  NENUID  —  Contains  the  identification  of  the  desired  aenu/help  data. 

13  C  NENUID  identifies  the  aenus  starting  record  nuaber  in  the 

19  C  aenu/help  file. 

20  C  HELPFL  —  Help  desired  flag.  If  this  itea  is  set  to  :ero  (0),  then 

21  C  aenu  data  will  be  presented,  all  other  values  will  result 

22  C  in  the  generation  of  help  data. 

23  C 

24  LOGICAL  NENVAL!768) 

25  INTEGER*!  NENSIZ,  NENLIN,  HLPSI2,  HLPLIN.  NLNSZ(12),  HLNSZ (12) 

26  INTEGER  ACTNEN,  HELPFL 

27  C0HN0N  /  HENDAT  /  NENSIZ,  NENLIN.  HLPSIZ.  HLPLIN.  HLNSZ,  HLNSZ, 

28  1  ACTHEN,  HENVAL 

29  C 

30  C  Check  ACTNEN  to  deterame  if  the  requested  aenu  data  is  currently 

31  C  active. 

32  C 

33  IF  (  ACTNEN  ,EQ.  NENUID  )  GO  TO  500 

34  ACTNEN  =  NENUID 

35  10  CONTINUE 

36  C 

37  C  Read  the  aenu  and  help  data  for  the  desired  aenu  froa  the  aenu/help 

38  C  file  and  store  in  the  coaaon  block  /HENDAT/. 

39  C 

40  READ!  7,  END=10,  ERR=10,  REC=NENUID  1  NENSIZ,  HLPSIZ.  NENLIN. 

41  1  HLPLIN.  (MLNSZU),  1=1,12),  4HLNSZ (I ) ,  1=1 . 12) 

42  ISTART  =  NENUID  +  l 

43  IST0P  =  NENUID  ♦  HLPSIZ  ♦  NENSIZ 

44  II  =  1 

45  12  =  128 

46  DO  100  I  =  ISTART.  IST0P 

47  READ  <  7.  END=10,  ERR=10.  REC=I  )  (MENVALU) . J=I  1, 12) 

43  II  »  II  *  128 

49  12  =  12  ♦  128 


50 

100  CONTINUE 

51 

500  CONTINUE 

52 

C 

53 

C  Detenine  if  aenu  data  or  help  data  should  be  displayed. 

54 

C 

55 

IF  (  HELPFL  .NE.  0  )  SO  TO  600 

56 

ISTART  =  1 

57 

C 

53 

C  Enter  loop  to  display  the  aenu  data  to  the  output  device. 

59 

C 

60 

DO  510  1=1.  HENLIN 

61 

ISTOP  =  ISTART  ♦  HLNSZ(I)  -  1 

62 

NRITE  (  5.  900  )  (  HENVAL(J),  J 

=  ISTART. 

ISTOP  ) 

63 

ISTART  =  ISTOP  *  1 

64 

510  CONTINUE 

65 

NRITE  (  5,  901  1 

66 

GO  TO  9999 

67 

600  CONTINUE 

63 

ISTART  =  (  MENS1Z  *  123  )  +  I 

69 

NRITE  (  5,  902  ) 

70 

C 

71 

C  Enter  loop  to  display  the  help  data  to  the  output  device. 

72 

C 

73 

DO  610  I  =  1.  HLPLIN 

74 

ISTOP  =  ISTART  ♦  HLNSZ(I)  -  1 

75 

NRITE  (  5,  900  )  (  MENVALU),  J 

=  ISTART, 

ISTOP  ) 

76 

ISTART  =  ISTOP  ♦  1 

77 

610  CONTINUE 

73 

NRITE  (  5.  902  ) 

79 

NRITE  (  5.  901  ) 

80 

900  FORHAT  (  1H  ,  80A1  ) 

81 

901  FORHAT  (  1H  ) 

82 

902  FORHAT  (  1H  ,  1  \  37(’-’)  ) 

83 

9999  CONTINUE 

84 

RETURN 

85 

END 

Prograa  Unit  Length=0239  !649)  Bytes 

Data  Area  lengtft=004B  (75)  Bvtes 

Subroutines  Referenced: 

*12 

4R5 

$ND 

*W2 

Variables: 

MENU ID 

0001'  HELPFL  0003* 

MENVAL 

/HENDAT/+001E 

HENS I Z 

/MEND AT / +0000  HENLIN  /MENDAT/+0001 

HLPSIZ 

/HENDAT/V0002 

HLPLIN 

/MENDAT/+0003  HLNSZ  /MENDAT/+0004 

HLNSZ 

/HENDAT/+0010 

ACTHEN 

/HENDAT/KiOlC  TI000002  0005* 

I 

oooc* 

PRTftNS  —  Print  Answer 

Processing  Description.  Following  each  problem  sol¬ 
ution,  PRTANS  is  called  to  give  the  user  the  opportunity  to 
examine  problem  results.  Before  the  solution  displays  are 
presented,  PRTANS  informs  the  user  if  any  special  conditions 
were  encountered.  These  special  conditions  are: 

—  no  solution 

—  unbounded  solution. 

If  an  unbounded  solution  was  detected,  PRTANS  will  inform 
the  user  of  the  problem  parameters  that  were  in  effect. 

At  this  point,  if  there  was  at  least  one  non— dominated 
solution,  PRTANS  asks  the  user  whether  he  wants  a  summary  of 
objective  values  or  detailed  solution  displays  on  one  or  all 
of  the  solutions.  Based  on  the  user’s  selection,  PRTANS 
will  generate  and  display  the  data.  Prior  to  display 
though,  the  user  is  asked  if  the  display  is  to  be  generated 
on  the  video  display  screen  or  to  be  routed  to  the  printer. 
After  each  display,  the  user  is  given  the  opportunity  to  get 
additional  solution  information.  NOTE:  Once  the  user  exits 
this  module,  the  solution  data  is  lost. 

Key  Local  Variables. 

IDEV  —  This  item  indicates  the  final  destination  for  solu¬ 
tion  displays.  It  is  set  to  5  for  the  video 
display  screen  or  set  to  2  for  the  printer. 

Module  Listing.  The  following  pages  contain  the 
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Created:  2 
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2  C 

3  C 

4  C 

5  C 

6  C 

7  C 

8  C 

9  C 

10  c 

u  c 

12  C 

13  C 

14 

15 

16 

17 

18 

19 

20 
2! 

22 

23 

24 

25 

26 

27 

28 

29 

30  C 

31  C 

32  C 

33  C 

34  C 

35  C 

36 

37 

38 

39 

40 

41 

42 

43  C 

44  C 

45  C 

46  C 

47  C 

48  C 

49 
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SUBROUTINE  PRTANS 
Subroutine  PRTANS  --  Print  answer 

This  subroutine  is  invoked  after  every  problea  solution.  Through 
this  progras,  the  user  is  given  the  option  of  viewing  I  either  on  the 
screen  or  on  the  printer  )  problea  results.  For  problems  that  were 
solved  with  the  weighting  technique,  the  user  is  also  given  the 
option  of  having  displays  include  the  objective  weights  the  go  with 
the  solutions. 


This  routine  has  no  calling  paraaeters 
LOGICAL  TXTVAL 432) ,  L8(2).  LX 44) 

REAL  W!4),  08(4).  LB(4),  DEL (4).  ZF(4),  0BJVAII30.4),  F'I30). 

1  VARVAL 430, 10) ,  DUO, 31),  C0NU0.10),  QBJ<4,10),  RHS(IO) 

REAL  S0LWHT (30, 4) ,  UBHHT (4) 0BX(4> 

REAL*8  SUSP.  SLACK,  VV 

REAL*8  CNAMEU0),  0NAME(4),  FNAME 

INTEGER  IBV(IO).  1STRT,  NNDS 

INTEGERU  SPCFLG,  VARNUH<30.10),  CNXREF(IO).  JJ. 

1  CTYPE  UO),  0TYPE(4) ,  NCON,  NOBJ,  NVAR,  NCQNX 

COMMON  /  PROS  /  CON,  CNAHE,  CTYPE,  RHS,  OBJ,  ONAME.  OTYPE.  NCON, 

1  NOBJ,  NVAR,  FNAME 

COMMON  /  SGLN  /  N,  UB.  LB.  DEL.  1STRT,  P.  D.  IBV.  SQLNHT,  VARNUM, 

1  VARVAL,  OBJOhL,  IF,  HMDS,  CNYREF,  SPCFL8,  U8HHT, 

2  ICAP 

DATA  SURP,  SLACK  /  ’SURPLUS  ’  .  ’SLACK  ’  / 

DATA  LIU),  LX (2) ,  LX 43) ,  U<4)  /  32,  32,  32,  32  / 

Before  printing,  we  aust  count  the  nuaber  of  greater  than  constraints 
and  the  nuaber  of  equal  constraints.  These  counts  are  needed  in 
order  to  deteraine  which  variables  are  slacks/surpluses  for  which 
constraints. 

IC1  =  0 
IC2  =  0 

DO  5  J  =  1.  NCON 

IF  (  CTYPE ( J )  .E9.  3  >  IC1  =  IC1  +  1 
IF  (  CTYPE ( J )  .EQ.  2  )  IC2  =  IC2  +  1 
5  CONTINUE 

III  =  (  ISTRT  -  1  )  »  (  NOBJ  -  1  > 

Set  NCONX  equal  to  the  nuaber  basic  variables.  NOTE:  It  variec 
depending  on  the  type  of  solution  technique.  If  weighting 
technique  then  NCON)  =  NCON.  If  constraint  technique  then 
NCONX  =  NCON  +  NOBJ  -  1. 

NCONX  =  NCON  Mil 


50  C 

51  C  Set  111  equal  to  the  -first  variable  that  corresponds  to  the  less 

52  C  than  constraints.  It  is  used  to  deteraine  which  variables  are 

53  C  slacks  as  follows: 

54  C  If  variable  nuaoer  <=  NVAR  then  it  is  a  decision  variable 

55  C  If  variable  nuaber  >  NVAR  but  <  III  then  it  is  a  SURPLUS. 

56  C  If  variable  nuaber  >111  then  it  is  a  SLACK. 

57  C 

58  III  =  I  NVAR  *  III  +  ICS  M  ICl  *  2  >  ) 

59  10  CONTINUE 

60  C 

61  C  Clear  the  screen 

62  C 

63  WRITE  (  5,  900  ) 

64  C 

65  C  Check  to  see  if  there  were  no  NNDS  and  no  unbounded  solutions.  If 

66  C  none  of  either  then  tell  the  user  to  reformists  and  trv  again. 

67  C 

68  IF  (  NNDS  ,NE.  0  .08.  SFCFLS  ,NE.  0  )  B0  TO  50 

69  CALL  6ETTXT  i  218.  0.  32.  0.  TXTVAL.  1  ) 

70  60  TO  999? 

71  50  CONTINUE 

72  C 

73  C  Check  to  see  if  solution  was  not  unbounded. 

74  C 

75  IF  (  SPCFL8  .E9.  0  )  B0  TO  80 

76  C 

77  C  Check  to  see  if  there  was  oniv  one  objective. 

78  C 

79  IF  (  N0BJ  .NE.  1  )  SO  TO  55 

80  C 

81  C  Tell  user  that  his  single  objective  problea  was  unbounded. 

82  C 

83  CALL  6ETTXT  (  228.  0,  32.  0,  TXTVAL,  1  ) 

84  GO  TO  9999 

35  55  CONTINUE 

86  C 

87  C  The  following  section  of  code  displays  the  first  weights  that  were 

88  C  used  when  an  unbounded  solution  was  obtained.  NOTE:  Heights 

69  C  refers  to  both  weights  and  constraint  limits  depending  on  the 

90  C  solution  type. 

91  C 

92  CALL  PRSMEN  (  224.  0  ) 

93  IF  (  ISTRT  ,E9.  2  !  WRITE  i  5.  902  i 

94  IF  i  ISTRT  .Efl.  1  )  WRITE  (  5,  903  ) 

95  WRITE  (  5.  904  1 

96  DO  60  I  =  ISTRT,  N0BJ 

97  WRITE  I  5.  905  I  I.  ONAHE(I),  UBWHT(I) 

99  60  CONTINUE 

99  CALL  6ETTXT  (  122.  0.  32.  0.  TXTVAL.  1  ) 

100  80  CONTINUE 


224 


101  c 

02  C  Tell  user  hot*  sanv  non-doainated  solutions  were  obtained. 

[03  C 

04  WRITE  (  5,  901  )  HMDS 

105  IF  (  HMDS  .NE.  0  )  GO  TO  100 

06  CALL  GETTXT  (  122.  0.  32.  0,  TXTVAL,  1  ) 

107  GO  TO  9999 

08  100  CONTINUE 

109  C 

10  C  If  sore  then  the  upper  lisit  at  30  solutions  was  obtained,  intora  the 
111  C  user  of  that  fact. 

12  C 

13  IF  (  I  CAP  .NE.  0  )  CALL  P.RSNEN  (  252,  0  ) 

114  C 

15  C  Ask  the  user  which  type  of  solution  display  he  desires. 

116  C  1  --  objective  suiaary  displav 

17  C  2  --  detailed  solution  display,  one  solution 

118  C  3  --  detailed  solution  display,  all  solution 

19  C  0  —  EXIT  display  sodule 

120  C 

21  CALL  GETINT  (  233,  0.  3,  0,  ITYPE  ) 

122  GO  TO  I  110,  105,  102  ),  ITYPE 

23  GO  TO  9999 

124  102  CONTINUE 

25  C 

26  C  User  has  requested  to  see  details  on  all  solutions.  Set  displav 

;27  C  loop  Units. 

23  C 

129  II  =  1 

30  12  =  NNDS 

131  GO  TO  103 

32  105  CONTINUE 

133  C 

34  C  User  has  requested  details  on  just  one  solution,  ask  him  which  one. 
135  C 

36  CALL  GETINT  (  214,  0,  NNDS,  1.  II  ) 

137  12  =  II 

38  108  CONTINUE 

139  IWGHT  =  2 

40  C 

41  C  If  this  was  a  weighting  technique  solution,  ask  user  if  he  would  like 
.42  C  hi 5  displays  to  show  reoresentative  objective  weights. 

43  C 

44  IF  (  ISTRT  .EQ.  2  )  SO  TO  110 

.45  CALL  GETINT  (  239,  0,  2,  1,  IWGHT  ) 

46  110  CONTINUE 

,47  C 

48  C  Ask  user  where  to  generate  the  requested  solution  displav 

49  C  1  —  Displav  screen 

50  C  2  —  Printer 

51  C 


WLX.  J 


CALL  6ETINT  (  244.  0,  2,  1,  IBEV  ) 

WRITE  !  5,  900  ) 

IF  (  IBEV  .EQ.  1  )  SO  TO  200 
C 

C  User  has  requested  printer.  Give  hi  a  instructions  and  *ait  for  ack 
C  nonledoesent. 

C 

CALL  GETTXT  (  248,  0.  32,  0.  TXTVAL,  1  ) 

SO  TO  210 
200  CONTINUE 
IDEV  =  5 
210  CONTINUE 

IF  (  I TYPE  .BE.  2  )  80  TO  240 
C 

C  Beain  code  for  generating  the  objective  value  suaaary. 

C 

WRITE  (  IDEV,  908  )  (  QNANE(I),  1=1,  NOBJ  ) 

WRITE  (  IDEV,  913  )  (  LX ( 1 ) ,  I  =  1,  NOBJ  i 
DO  230  1=1,  NHDS 
DO  220  J  =  1,  NOBJ 
OBX(J)  =  OBJVAL(I.J) 

220  CONTINUE 

WRITE  (  IDEV,  917  )  I,  (  OBXfJ),  J  =  1,  NOBJ  ) 

230  CONTINUE 

IF  (  IDEV  .E9.  2  )  GO  TO  810 
WRITE  I  5,  919  ) 

READ  (  5.  915  )  II 
WRITE  (  5,  900  ) 

GO  TO  10 
240  CONTINUE 
C 

C  Begin  code  to  generate  detailed  solution  displays. 

C 

WRITE  (  IDEV.  906  )  FNAHE 
C 

C  Enter  loop  to  process  the  requested  nusber  of  solutions 
C  fie  all  or  one  in  particular) 

C 

DO  800  I  =  II,  12 
WRITE  (  IDEV,  907  )  I 
C 

C  Enter  loop  to  output  objective  values, 

C 

DO  300  J  =  1,  NOBJ 
OB  =  OBJVAL(I.J) 

IF  (  IWGHT  .ES.  1  )  GO  TO  250 
WRITE  (  IDEV.  909  )  J,  ONANEiJ).  OB 
GO  TO  300 
250  CONTINUE 

WRITE  (  IDEV.  910  )  J.  ONANE(J),  OB,  SQLWHTil.J) 

300  CONTINUE 


203  C 

2 »4  C  The  following  loop  is  designed  to  allow  processing  of  the  three 

205  C  tvpes  of  variables  I  decision,  slack,  surplus  )  in  order. 

206  C 

207  CO  600  X  =  1 ,  3 

208  IF  (  K  .ST.  1  )  BO  TO  380 

209  WRITE  (  IDEV,  911  ) 

210  SO  TO  400 

211  330  CONTINUE 

212  IF  (  K  .ST.  2  )  60  TO  400 

213  WRITE  (  IDEV,  916  ) 

214  400  CONTINUE 

215  C 

216  C  Enter  loop  to  search  of  of  the  basic  variables  for  one  of  the  3 

21^  c  tvpes  (  deoending  on  the  value  of  loop  variable  K  ). 

218  C 

21?  DO  500  J  =  1.  NCQNX 

220  AX  =  VARVAL ( I , J ! 

221  C 

222  C  Don't  display  uninterestino  basic  varibales  that  are  equal  to  0. 

223  C 

224  IF  (  AX  .Ed,  0.0  )  SO  TO  500 

225  JJ  =  VARNUfld,  J) 

226  IF  I  K  .GT.  1  )  GO  TO  450 

227  C 

228  C  This  section  processes  decision  variables  (  K  =  1  ). 

229  C 

230  IF  !  J.)  .ST.  NVAR  )  BO  TO  500 

231  ENCODE  (  L6,  915  1  JJ 

232  IF  (  JJ  .GE.  10  )  60  TO  420 

2  33  LS(l)  =  1.3(2) 

234  LB (2)  =  32 

235  420  CONTINUE 

236  WRITE  (  IDEV.  912  )  LS(1).  LS(2) ,  AX 

237  GO  TO  500 

238  450  CONTINUE 

239  II  =  JJ  -  NVAR 

240  IF  (  K  .GT.  2  )  GO  TO  460 

241  C 

242  C  This  section  processes  SURPLUS  variables  (  K  =  2  ). 

243  C 

244  IF  (  JJ  .GT.  I1Y  .OR.  JO  .LE.  NVAR  )  GO  TO  500 

245  VV  -  SURE 

246  GO  TO  430 

247  460  CONTINUE 

248  C 

24?  C  This  section  processes  SLACK  variables  <  K  =  3  ) . 

250  C 

251  IF  (  JJ  .LE.  Ill  )  GO  TO  500 

252  II  -  II  -  IC1 

253  VV  =  SLACK 


227 


254  480  CONTINUE 

255  II  =  CNXREF(II) 

256  WRITE  (  IDEV,  914  )  II,  CNAMEUI),  VV,  fix 

257  500  CONTINUE 

258  600  CONTINUE 

259  610  CONTINUE 

260  IF  (  IDEV  .NE.  2  )  60  TO  650 

261  C 


262 

C  For  printer  outputs,  do  a  page  eject. 

26J 

C 

264 

WRITE  ( 

2,  918  ) 

265 

60  TO  800 

266 

650  CONTINUE 

267 

C 

268 

C  For  screen 

outputs,  ask  user  for  input  before  going  on. 

269 

C 

270 

WRITE  ( 

5,  919  ) 

271 

READ  (  5,  915  )  II 

272 

WRITE  ( 

5,  900  ) 

273 

800  CONTINUE 

274 

810  CONTINUE 

275 

IF  (  IDEV  ,E6.  2  )  WRITE  (  2.  900  ) 

276 

GO  TO  10 

277 

900  FORMAT  ( 

1H1  ) 

278 

901  FORMAT  ( 

1 H 1 ,  ’There  were  12,  ’  NON-DOMINATED  solutions 

279 

1 

’found.’,  /  ) 

280 

902  FORMAT  ( 

1H0,  14X,  ’OBJECTIVE’,  9X,  ’LIMIT’  ) 

281 

903  FORMAT  ( 

1H0,  14X,  ’OBJECTIVE’,  9J,  ’WEIGHT’  ) 

232 

904  FORHAT  ( 

1H  ,  13X,  ’ - ’,  7X,  ’ - ’  ) 

283 

905  FORMAT  ( 

1H  ,  13X,  11,  ’.  A8,  7X,  F8.2  > 

284 

906  FORMAT  ( 

1H  ,  18X,  ’NON-DOMINATED  SOLUTIONS  FOR  PROBLEM:  ’,  A8  ) 

285 

907  FORMAT  ( 

1H0,  30X,  ’*♦*  SOLUTION  ’,  12,  ’  *«’,  //, 

286 

1 

’  29X,  ’ - OBJECTIVES - ’  ) 

287 

908  FORMAT  ( 

1H  ,  10X,  'SUMMARY  OF  OBJECTIVE  VALUES  FOR  THE  NON-’, 

238 

1 

'DOMINATED  SOLUTIONS’,  15X. 

289 

2 

’OBJECTIVES - ’,  /,  ’  ’,  2.X,  ’SOLUTION’, 

290 

3 

4(7X,A8)  ) 

291 

909  FORMAT  ( 

1H  ,  26X,  12,  ’.  AS,  ’  =  ’,  F12.4  ) 

292 

910  FORMAT  1 

1H  ,  13X,  12,  ’.  A8.  ’  =  ’,  F12.4,  5X.  ’(  WEIGHT  =  ’ 

293 

1 

F7.5,  ’  >’  ) 

294 

911  FORMAT  ! 

1H0,  29X,  ’ - VARIABLES - ’  ) 

295 

912  FORMAT  ( 

1H  ,  22X,  ’Decision  variable  x’,  2A1,  ’  =  ’,  F12.4  ) 

296 

913  FORMAT  ( 

1H  ,  2X,  ’ - ’,  2X,  4(2X,A1,’ - ’)  ) 

297 

914  FORMAT  ( 

1H  ,  12X,  ’Constraint’,  12,  ’  (  ’,  A8, 

298 

1 

'  )  had  a  ’,  A8,  '=  ’,  F12.4  ) 

299 

915  FORMAT  < 

12  ) 

300 

916  FORMAT  ( 

1H0,  20X,  ’ - CONSTRAINT  SLACKS/SURPLUSES - ’  ) 

301 

917  FORMAT  ( 

1H  ,  5X.  12.  5X,  4(3X,F12.4)  ) 

302 

918  FORMAT  ( 

1H  ,  20  ( ’ - ’ )  ) 

303 

919  FORMAT  ( 

1H0,  20 X,  ’—  PRESS  THE  RETURN  KEY  TO  CONTINUE  — ’  ) 

304 

9*599  CONTINUE 

228 


Pro? ran  Unit  Length=0S68  (2152)  Bytes 
Data  Area  Length=042B  (1067)  Bytes 


Subroutines  Relerenced: 


$13 

$12 

$11 

$10 

$(19 

m 

$N0 

SETTXT 

PRSMEN 

SET I NT 

$CS 

$L1 

$T1 

$MA 

$NB 

$R2 

$QE 

$L3 

$13 

Variables: 

TXTVAL 

ooor 

LG 

0021* 

LX 

0023* 

M 

/50LN/+0000 

UB 

/SQLN/+0010 

LB 

/S0LN/+0020 

DEL 

/S0LN/+0030 

ZF 

/SOLN/+OF42 

OBJVAL 

/SOLN/+OB62 

P 

/S0LN/+0042 

VARVAL 

/S0LN/+08B2 

D 

7SOLN/+OOBA 

CON 

/PR0B/+0000 

OBJ 

/PR.0B/+0212 

RHS 

/PR0B/+01EA 

SQLHHT 

7SOLN/+05A6 

USWHT 

/S0LN/+0F5F 

OBX 

0027* 

SURP 

0037* 

SLACK 

003F* 

VV 

0047* 

CNANE 

/PRQ8/+0190 

ONAME 

/PR08/+02B2 

FNAME 

/PR0B/+02D9 

I BV 

/S0LN/+0592 

ISTRT 

/S0LN/+0040 

NNDS 

/S0LN/+0F52 

SPCFLS 

/SQLH/+0F5E 

VARNUK 

/S0LN/+078S 

CttXREF 

/S0LNMF54 

JJ 

004F' 

CTVPE 

/'PRQB/+01E0 

OTVPE 

/PR0B/+02D2 

NCQN 

/PR0B/+02D6 

NQBJ 

/PR0B/+02D7 

NVAR 

/PRQB/+02D8 

NCONX 

0050* 

ICAP 

/S0LN/+0F6F 

IC1 

0051* 

IC2 

0053' 

l 

0055’ 

T:  000002  005' 

III 

0058* 

T: 010002  005A" 

I 

OOAB* 

T: 000000  006D‘ 

T: 010000  006F* 

ITYPE 

0081* 

11 

0089' 

12 

0088 1 

IWBHT 

0093* 

I  DEV 

009B' 

II 

OOAB" 

OB 

00AD“ 

T: 020000  00B1 ' 

K 

0083" 

AX 

00B5* 

COMMON 

Length 

/PR08/02E1  (737) 

/S0LN/0F71  (3953) 

PRTPRB  —  Print  Problem 

Processing  Description.  PRTPRB  is  called  for  the  pur — 
pose  of  generating  a  display  of  the  current  problem  whenever 
the  user  enters  "*§"  or  "©P" .  The  added  "P"  is  used  to 
indicate  that  the  display  should  be  routed  to  the  printer 
rather  than  the  video  display  screen. 

The  display  format  is  the  same  for  both  the  printer  and 
the  screen.  PRTPRB  extracts  all  the  necessary  problem 
information  from  the  problem  common  block  (PROS). 

Key  Local  Variables.  Refer  to  the  module  listing. 


FORTRAN-SO  Ver.  3. 43  Copyright  1978*1981  (0  By  Microsoft  --  Bytes:  25131 
Created:  27-Jun-81 

1  SUBROUTINE  PSTFRB  (  IDEV  ) 

2  C 

3  C  Subroutine  PRTPR8  —  Print  Problea 

4  C 

5  C  This  subroutine  is  invoked  whenever  the  user  inputs  “2‘  or  '8P'  in 

6  C  response  to  any  PCADA  proapt.  It  is  designed  to  output  the  contents 

7  C  ot  the  coaaon  block  /  PROB  /  to  the  line  printer  (  for  *§P*  )  or  to 

8  C  the  screen  (  for  *8“  ).  The  saae  foraat  is  used  for  both  outputs. 

9  C  The  only  distinguishing  feature  between  the  to  types  of  outputs  is 

10  C  the  device  (  IDEV  ) . 

11  C 

12  C  paraseter  description  — 

13  C 

14  C  IDEV  —  This  itea  identifies  the  device  to  which  the  output  is  to  be 

15  C  directed, 

la  C 

17  LOGICAL  LINE1I23).  LINE2!4S).  LINE3114),  LINE4U3) 

13  REAL  OBT (3) 

19  REAL  CQN(KUO).  083(4, 10),  RHSUO) 

20  REAL *8  CNAMEllO! ,  ONAME (4),  FNANE 

21  INTEGER*!  CTYPE(IO).  0TYPE<4>,  NCON.  NOBJ,  NVAR 

22  COMMON  /  PROB  /  CON.  CNAME,  CTYPE,  RHS,  OBJ,  ONAME,  OTYPE,  NCON, 

23  1  NOBJ.  NVAR,  FNAHE 

24  DATA  OBT  /  ’MAXI’,  ’MINI’,  ’MIZE’  / 

25  C 

2fa  C  If  the  display  is  Doing  to  the  screen,  dear  it. 

27  C 

23  IF  I  IDEV  .Efl.  5  )  WRITE  (  5,  906  ) 

29  C 

30  C  Write  proble*  nase  and  header 

31  C 

32  WRITE  (  IDEV,  900  )  FRAME 

33  C 

34  C  Enter  loop  to  write  out  the  objectives 

35  C  NOTE:  The  output  of  the  objectives  uses  2  i teas:  LINE1  and  LINE2. 

36  C  LINE1  contains  the  objective  nuaber,  objective  naee,  and 

37  C  objective  type.  LINE1  is  output  only  on  the  first  line  for  the 

38  C  objective.  LINE2  contains  ANSII  dat  for  up  to  4  variables,  it  is 

39  C  set  by  repeated  calls  to  CBELIN,  After  the  first  line,  LINE1  is 

40  C  blanked  out. 

41  C 

42  DO  10  I  =  1.  43 

43  LINE2U)  =  32 

44  10  CONTINUE 

45  DO  40  1=1,  NOBJ 

46  II  =  OTYPE ( I ) 

47  ENCODE  (  LINE  1 ,  901  )  I,  OBT! ID,  OBT (3).  ONAME ! I ) 

48  II  =  1 

49  DO  30  J  =  1,  NVAR 


232 


CALL  CDELIN  I  OBJ(I.J).  LINE2,  Ii,  i  ) 

Determine  if  a  line  should  be  printed. 

IF  (  J  .NE.  NVAR  .AND.  J  ,N£.  4  .AND.  J  .NE,  8  !  60  TO  30 
WRITE  (  I  DEV,  902  )  (  LINE1 (K).  K  =  1,  23  ), 

1  (  LINE2IL),  L  =  1.  48  ) 

Enter  loop  to  blank  out  LINE1  and  LINE2.  NOTE:  It  is  ESSENTIAL 
that  LINE1  and  LINE2  physically  reside  sequentially  since  the 
following  single  loop  is  used  to  blank  out  both  of  thea. 

DO  25  K  =  1.  71 
LINE1 <K>  =  32 
25  CONTINUE 
II  =  1 
30  CONTINUE 

WRITE  (  IDEV,  907  ) 

40  CONTINUE 

Write  out  the  constraint  header 
WRITE  (  IDEV,  903  ) 

Enter  Iood  to  output  the  constraints. 

NOTE:  This  output  uses  LINES,  LINE2,  and  LINE4.  LINE2  is  used  as 
noted  above,  LINE3  is  used  only  for  the  first  line  of  each  con¬ 
straint  and  contains  the  constraint  nuaber  and  nane.  LINE4  is 
used  only  for  the  last  line  of  the  constraint  and  contains  the 
constraint  sign  and  the  right  hand  side  value. 

DO  100  1=1,  NCQN 

Enter  loop  to  blank  out  LINE4 

DO  45  K  =  1.  13 
LINE4IK)  =  32 
45  CONTINUE 

ENCODE  (  LINE3.  904  )  I,  CNANEil) 

II  =  1 

Enter  loop  to  process  each  of  the  variables. 


DO  60  J  =  1,  NVAR 

CALL  CDELIN  (  C0N(I,J),  LINE2,  II,  J  l 

IF  (  .J  .NE.  NVAR  .AND.  i  .NE.  4  .AND.  J  .NE.  8  )  GO  TO  60 

IF  (  J  .NE.  NVAR  )  60  TO  50 

ENCODE  (  LINE4,  905  )  RHS(I) 

LINE4I3)  =  61 

IF  (  CTYPE(I)  .EQ.  2  )  GO  TO  50 
LINE4I2)  =  CTYPE(I)  +  59 


101  50  CONTINUE 

102  WRITE  i  IDEV,  902  )  (  LINE30O,  K  =  1,  14  ) . 

103  1  (  LINE2(U.  L  =  1.  48  ), 

104  2  (  LINE4(M),  H  =  1.  13  ) 

105  C 

106  C  Enter  loop  to  blank  out  LINE2  and  LIME3,  As  above,  they  #ust 

107  C  side  sequentially. 

108  C 

109  DO  55  K  =  1,  62 

110  LINE20O  =  32 

111  55  CONTINUE 

112  II  =  1 

113  60  CONTINUE 

114  WRITE  (  IDEV,  907  i 

115  100  CONTINUE 

116  C 

117  C  If  output  is  goinq  to  the  printer,  do  a  for®  feed. 

118  C 

119  IF  i  IDEV  .EQ.  2  )  WRITE  (  2,  906  ) 

120  900  FORMAT  (  1H  , ’PROBLEM  NAME  =  ’,  A8.  //. 

121  1  ’ - OBJECTIVES - /  ) 

122  901  FORMAT  (  12,  ’.  2A4,  ’  ’,  A8.  ’=  ’  ) 

123  902  FORMAT  (  1H  .  75A1  ) 

124  903  FORMAT  (  1H0,  ’ -  SUBJECT  TO  THE  FOLLOW INS  CONSTRAINTS’ 

125  1  ’ - ’,  /  ) 

126  904  FORMAT  (  12,  '.  ’,A8,  ’  ) 

127  905  FORMAT  (  ’  F8.2  ) 

129  906  FORMAT  1  1M  1 

129  907  FORMAT  (  1H  ) 

130  RETURN 

131  END 


Progra®  Unit  Ler»gth=0474  (1140)  Bytes 
Data  Area  Length=0150  (336)  Bvtes 

Subroutines  Referenced: 


*13 

*32 

*11 

*10 

*H2 

*ND 

JOE 

CDELIN 

*M9 

Variables: 

IDEV 

0001* 

LINE1 

0003* 

LINE2 

001  A* 

LINE3 

004A* 

LINE4 

0058" 

OBT 

0065* 

CON 

/PR0B/+0000 

OBJ 

/PR08/+0212 

RHS 

/PRQB/+01EA 

CNAHE 

/PR0B/+0190 

ONAME 

/PROB/+02B2 

FNAME 

/PR0B/+02D9 

CTYPE 

/PR0B/+01 EO 

OTYPE 

/PR0B/+02D2 

NCON 

/PR0B/+02De 

NOBJ 

/PR0B/+02D7 

NVAfi 

/PR0B/+02D8 

T 1000002  0071 

I 

0072* 

T : OOOOOC 

i  0074* 

II 

0076* 

T: 01 0000  0078' 

J 

007A- 

T: 010002  0080 

0084 


T: 020002  0081“  K  0082“  L 

H  008A‘  T : 020000  008C* 

COflHON  Length 

/PRGB/02E1  (737) 

Labels; 


9Q6L 

0146" 

900L 

OOSE” 

10L 

0057’ 

40L 

01 F5' 

90 1L 

00C7" 

30L 

0105' 

902L 

OOEO* 

25L 

01C2' 

907L 

014B* 

903L 

OOEfl" 

100L 

042E’ 

45L 

0231’ 

904L 

0127“ 

60L 

040E  ’ 

SOL 

035E’ 

905L 

0138“ 

SSL 

03FB’ 

FORTRAN— 90  Ver,  3.43  Copyright  1978-1981  (0  Bv  Microsoft  —  Bvtes:  25131 
Created:  27-Jun-Sl 

1  SUBROUTINE  SAVPRB  i  ISTAT  ) 

2  C 

3  C  Subroutine  SAVPR8  --  Save  probles 

4  C 

5  C  This  subroutine  is  designed  to  save  the  current  problem,  as  contained 

6  C  in  the  cession  block  /PROS/  to  the  diskfile  identified  by  FNANE. 

7  C  It  is  invoked  autosaticallv  following  problea  definition  or  following 

8  C  probles  editing. 

9  C 

10  C  Paraaeter  description 

11  C 

12  C  ISTAT  —  This  i tea  is  returned  to  the  calling  prograst  to  indicate  the 

13  C  status  of  the  save  action.  A  zero  value  indicates  that  the 

14  C  problea  was  successfully  saved.  A  non-cero  value  indicates 

15  C  that  soae  probles  was  encountered. 

14  C 

17  INTEGERS  CTYPEilO),  0TYPE14),  NCON.  N08J.  NVAR 

18  REAL  CONI  10, 10),  0BJ(4,10),  RHS(IO) 

19  REAL*8  CNAHE(IO),  QNAME(4),  FNAME 

20  COMMON  /PRQB  /  CON,  CNAME.  CTYPE,  RHS.  OBJ,  ONAME,  QTYPE,  NCON. 

21  1  NQBJ ,  NVAR,  FNAME 

22  C 

23  C  Set  the  status  flao  to  indicate  no  problea 

24  C 

25  ISTAT  =  0 

24  C 

27  C  write  the  controlling  data  to  the  first  record,  note:  if  an  i/'o 

28  C  error  occurs,  control  will  revert  to  stateaent  10 

29  C 

30  WRITE  (  8.  ERR=10,  END=10,  REC=1  )  NCON,  NOBJ,  NVAR 

31  80  TO  20 

32  10  CONTINUE 

33  C 

34  C  set  status  flag  to  indicate  that  an  I/O  error  has  occured. 

35  C 

36  ISTAT  -  1 

37  60  TO  9999 

38  20  CONTINUE 

39  C 

40  C  loop  on  the  nuaber  of  objectives  to  write  the  objective  data  to  the 

41  C  file  to  be  saved. 

42  C 

43  DO  30  I  =  1.  NQBJ 

44  IREC  =1+1 

45  WRITE  (  8.  ERR= 1 0 .  END=10,  REC=IREC  )  ONAME  (I) ,  QTYPEtP, 

46  1  (  OBJ ( I , J ) ,  J  =  1.  NVAR  ) 

4?  30  CONTINUE 

48  C 

49  C  loop  on  the  nuaber  of  constraints  to  save  the  constraint  data  to  the 


50  C  file  to  be  saved. 

51  C 

52  DO  40  I  =  1,  NCON 

53  IftEC  =  I  +  1  +  NOBJ 

54  WRITE  (  8.  ERR=1 0 ,  END=10,  REC=iREC  )  CMAME(I),  CTYPE(I) 

55  1  (  CONd.J),  J  =  1.  NVAR  ).  RHS(I) 

56  40  CONTINUE 

57  9999  CONTINUE 

58  ENDFILE  8 

59  RETURN 

60  END 

Proqra#  Unit  Length=01AF  1431)  Bytes 
Data  Area  Lenoth=002?  (41)  Bytes 

Subroutines  Referenced: 

$13  $12  $11 

$W5  $ND  $M9 

$EN 


Variables: 


ISTAT 

ooor 

CTVPE 

/PR0B/+01E0 

OTYPE 

/PR0B/+02D2 

NCON 

/PR0B/+02D6 

NOBJ 

/PR0B/+02B7 

NVAR 

/PR0B/+O2D8 

CON 

/PR0B/+0000 

OBJ 

/PR0B/+0212 

RHS 

/PR0B./+01EA 

CNAME 

/PROB/+0190 

ONAME 

/PR0B/+02B2 

FRAME 

/PROB/+02D9 

1 

OOOD" 

1REC 

000F“ 

J 

0017“ 

T : 000000  0019*  T: 010000  001 B'  T : 020000  001D" 

T: 030000  00 1 F  *  T: 040000  0027“ 


COMMON  Length 
/PRQB/02E1  (737) 

Labels: 

10L  002D’  20L  003A’  9999L  019C’ 


SOLVE 


Solve  Problem 


Processing  Description.  This  subroutine  is  called  by 
PRBSLV  after  the  user  has  specified  all  solution  parameters. 
SOLVE  repeatedly  calls  CSOLVE  or  WSOLVE  to  process  each 


iteration. 

The 

purpose  of 

SOLVE 

i  s  to 

determi ne 

the 

"weights'* 

to  be 

used 

for 

the  next 

iteration. 

NOTE: 

SOLVE 

works  the 

same 

for 

both 

the  weighting 

and 

constrai nt 

techniques.  That  is,  the  weights  are  incremented  using  the 
user  supplied  increment  between  the  user  supplied  lower  and 
upper  limits. 

Key  Local  Variables.  Refer  to  the  module  listing. 
Module  Listing.  The  following  pages  contain  the 


FORTRAN  compilation  listing  for  SOLVE 


FDRTRAN-80  Ver.  3.43  Copyright  1978-1991  (C)  By  Microsoft  --  Bvtes:  25131 
Created:  27-Jun-81 

1  SUBROUTINE  SOLVE  <  ITER  ) 

2  C 

3  C  Subroutine  SOLVE  --  Solve  probiea 

4  C 

5  C  This  progras  is  called  bv  PRBSLV  to  further  process  the  probiea 

6  C  solution.  It  dGes  so  bv  iterating  on  the  objective  weights  (  for  the 

7  C  weigting  techniaue  )  or  the  constraint  liaits  i  for  the  constraint 

8  C  techniaue  ).  and  calling  WSQLVE/CSOLVE  for  each  legitiaate  probiea. 

9  C 

10  C  SOLVE  does  not  use  any  calling  paraaeters. 

11  C 

12  REAL  P (30) .  D < 10, 31 ) 

13  REAL  SGLWHT (30,4) ,  UBWHTI4) 

14  REAL  ZF(4),  08JVALi30.4),  VARVAU30.10) 

15  INTEGER  I8VU01 

16  REAL  N(4),  UB(4i.  L8<4>,  DEL (4),  CQN(IO.IO),  0BJ(4,10),  RHS(IO) 

17  REAL *8  CNAME(IO),  0NAME!4>,  FNAHE 

18  INTEGER*!  SPCFL6.  VARNUH(30.10).  CNXREF(IO) 

19  INTEGER*!  CTYPE(IO),  0TYPEI4),  NCON,  NOBJ,  NVAR 

20  COMMON  /  PROS  /  CON,  CNAHE,  CTYPE,  RHS,  OBJ,  ONAME.  OTYPE,  NCON, 

21  1  NOBJ,  NVAR,  FNAME 

22  COMMON  /  SOLN  /  W,  UB,  LB,  DEL,  ISTRT,  P,  D,  IBV,  SOLNHT.  VARNUM. 

23  1  VARVAL,  OBJVAL,  ZF,  NNDS,  CM! REF,  SPCFLG.  UBWHT, 

24  2  I CAP 

25  C 

26  C  for  starters,  set  the  "weights”  equal  to  the  lower  liait.  NOTE*. 

27  C  the  weight  array  N  will  contain  weights  for  the  weighting  tech- 

28  C  nique  and  right  hand  side  values  for  the  constraint  technique.  The 

29  C  processing  by  this  prograa  is  the  saae  for  both.  The  "weight* 

30  C  siaply  assuaes  values  begining  at  the  lower  bound  and  increaenting 

31  C  bv  DEL  until  the  upper  bound  is  reached. 

32  C 

33  DO  100  1=1,  NOBJ 

34  H ( I)  =  LB  < I ) 

35  100  CONTINUE 

36  WRITE  (  5,  900  )  ITER 

37  II  =  1 

38  C 

39  C  enter  loop  to  process  every  possible  weight/constraint  coabination. 

40  C 

41  DO  400  1=1,  20000 

42  C 

43  C  for  constraint  technique  aust  juap  to  insure  that  we  process  the 

44  C  case  with  all  constraints  set  to  the  lower  bound. 

45  C 

46  IF  (  I  .EQ.  1  .AND.  ISTRT  .EQ.  2  )  SO  TO  350 

47  C 

48  C  enter  loop  to  increment  the  weights. 

49  C 


50  DO  300  J  =  ISTRT,  NOBJ 

51  IF  (  DEL(J)  ,EQ.  0.0  )  60  TO  200 

52  «(J>  =  N(J)  +  DEL ( J ) 

53  IF  (  W(J)  ,LT,  (  UB(J)  +  0.001  )  >  GO  TO  350 

54  W(J)  =  LB(J) 

55  200  CONTINUE 

56  IF  !  J  .EQ.  NOBJ  )  60  TO  9999 

57  300  CONTINUE 

53  350  CONTINUE 

59  C 

60  C  check  to  see  it  this  request  is  for  the  constraint  technique-ifso 

61  C  ail  that  needs  be  done  is  to  call  CSOLVE 

62  C 

63  IF  i  ISTRT  .,-iE.  2  )  60  TO  360 

64  WRITE  (  5.  901  )  II 

65  CALL  CSOLVE 

66  SO  TO  390 

67  360  CONTINUE 

63  C 

69  C  for  weighting  technique  requests,  we  sust  insure  that  the  weights  sui 

70  C  to  one,  ifso,  fine-call  NSOLVE,  otherwise,  throw  out  that  set  of 

71  C  weiohts  and  go  back  to  get  the  next  set, 

72  C 

73  SUN  =  0.0 

74  DO  380  J  =  1,  NOBJ 

75  SUN  =  SUM  +  W(J) 

76  380  CONTINUE 

77  IF  I  SUM  .ST.  1.001  .OR.  SUM  .IT.  0.999  1  SC  TO  400 

78  WRITE  (  5,  901  )  II 

79  CALL  WSQLVE 

80  390  CONTINUE 

81  IF  (  ICAP  .NE.  0  )  60  TO  9999 

82  It  =  II  +  l 

83  400  CONTINUE 

84  900  FORMAT  (  1H1.  Ill ,  ’  \  13X.  ’— >  MULTIOBJECTIVE  PROBLEM  \ 

85  1  ’SOLUTION  IN  PROCESS  III,  ’  ’,  30X,  'PLEASE  BE’, 

86  2  ’  PATIENT!’,  II,  ’  ’,  5X.  ’As  defined,  this  problem  will  ’, 

87  3  ’require  ’,  14,  ’  linear  program  iterations.’,  //, 

88  4  25X,  ’CURRENTLY  WORKING  ITERATION:’,  //  ) 

89  901  FORMAT  (  1H+,  34X,  ’m  14,  ’  ) 

90  9999  CONTINUE 

91  RETURN 

92  END 

Program  Unit  Length=023F  (5751  Bytes 
Data  Area  Length-0124  (292)  Bvtes 


Subroutines  Referenced: 


Variables: 

ITER 

OOOl1 

P 

/S0LN/+0042 

D 

/S0LN/+00BA 

SOLWHT 

/S0LM/+-05A6 

UBttHT 

/S0LN/+0F5F 

ZF 

/S0LN/+0F42 

OBJVAL 

/S0LN/+0D62 

VARVAL 

/SGLN/+0982 

IBV 

/SQLN/+0592 

H 

/SOLN/+UOOO 

UB 

/S0LN/+0010 

LB 

/S0LN/+0O20 

DEL 

/S0LN/+0030 

CON 

/FRQB/+0000 

OBJ 

/PR0B/+0212 

RHS 

/PR06/+01EA 

CNAME 

/PRG8/+0190 

ONAME 

/PR0B/+02B2 

FRAME 

/PR0B/+02D9 

SPCFL8 

/S0LN/+0F5E 

VARNUN 

/S0LN/+0784 

CMXREF 

/S0LN/+0F54 

CTYPE 

/PRQ8/+01E0 

OTYPE 

/PR0B/+02D2 

NOON 

/PRGS/+02D6 

NOBJ 

/PRGB/+02D7 

NVAR 

/PRGB/+02D8 

ISTRT 

/SQLN/+0040 

NNDS 

/SQLN/+0F52 

ICAP 

/SQLN/+0F4F 

I 

0003' 

T: 000000 

0005* 

t: oioooo  ooo; 

II 

0009" 

T 1000002 

OOOB" 

T: oiooo 

2  0001 

J 

GOOD* 

t: oooooi 

OOOF" 

SUM 

0013" 

COMMON 

Length 

/PRQB/02E1  (737) 
/S0LN/0F71  (3953) 

Labels: 

1 OOL 

0028’ 

900L 

0017" 

400L 

0219’ 

350L 

0149’ 

30  OL 

0135’ 

200L 

0114’ 

9599L 

0226’ 

34QL 

0176’ 

9011 

010A* 

Processing  Description.  This  module  is  responsible 
■for  calling  the  linear  programming  subroutine  (LP)  to  obtain 
a  problem  solution  using  the  weighting  technique.  Prior  to 
invoking  WSOLVE,  SOLVE  has  determined  from  the  user  the 
desired  objective  weights  and  increments.  WSOLVE  then  sets 
up  the  problem  in  the  format  required  by  LP,  and  then  calls 
LP  for  solution. 

Following  the  call  to  the  linear  programming  package, 
PROANS  is  called  to  examine  the  LP  solution  to  determine  if 
it  should  be  included  in  the  non-domi nated  solution  set. 
WSOLVE  is  called  once  by  SOLVE  for  each  iteration.  The  num¬ 
ber  of  iterations  is  determined  by  the  weights  and  weight 
increments  as  specified  by  the  user. 

Key  Local  Variables. 


IMULT  —  Flag  that  is  used  to  convert  objective  coefficients 
when  the  objective  is  to  be  minimized.  That  is, 
since  LP  only  maximizes,  for  objectives  to  be 
minimized,  the  coefficients  need  to  be  multiplied 
by  minus  1.  For  minimize  problems,  IMULT  will 
assume  the  value  of  -1,  for  maximize  problems,  it 
will  be  set  to  1 . 

Module  Listing.  The  following  pages  contain  the 


FORTRAN  compilation  listing  of  WSOLVE 


FORTRAN-80  Ver.  3.43  Copyright  1978-1981  <C)  By  Microsoft  --  Bytes:  25131 
Created:  27-Jun-31 

1  SUBROUTINE  NSOLVE 

2  C 

3  C  Subroutine  WSOLVE  --  Solve  proble*  with  the  weighting  technique 

4  C 

5  C  This  subroutine  is  called  by  SOLVE  whenever  a  proble*  is  to  be 

6  C  solved  with  the  weighting  technique.  Its  purpose  is  to  iteratively 

7  C  call  LP  with  different  weights  as  specified  bv  the  user.  It  does  so 

8  C  by  forsatting  the  proble*  and  *oving  its  description  fro»  /  PROB  / 

9  C  to  /  SOLM  /.  After  calling  LP.  this  subroutine  also  exaeines  the 

10  C  results  and  saves  the  nondoainated  solutions  for  later  processing. 

11  C 

12  C  This  subroutine  has  no  calling  paraaeters. 

13  C 

14  REAL  14(4) ,  UB<4>,  LB(4),  DEL14),  CON(IO.IO),  OBJ (4. 10) ,  RHSI10) 

15  REAL  SOLWHT (30,4),  U8WHTHS 

14  REAL  P (30) ,  D(10, 31) 

17  REAL  ZF(4),  0BJVAL!30,4I,  VARVAL (30. 10) 

18  INTEGER  IMULTH),  IBV(tO) 

19  REAL *8  CNAME(IO),  ONAMEM),  FNAME 

20  INTEGER*  1  SPCFLG,  VARNUM(30,101,  CNXREF(IO) 

21  INTEGER*!  CTVPEilO),  0TVPEH1,  NCON,  NOBJ,  NVAR 

22  COMMON  /  PROB  /  CON,  CNAME,  CTYPE,  RHS,  OBJ,  ONAME,  OTYPE,  NCON, 

23  1  NOBJ,  NVAR,  FNAME 

24  COMMON  /  SOLM  /  M,  UB,  LB,  DEL,  ISTRT,  P,  D,  IBV,  SDLHHT,  VARNUM. 

25  l  VARVAL.  OBJVAL,  ZF,  NNDS,  CNXREF.  SPCFLG,  UBMHT, 

24  2  ICAP 

27  C 

28  C  Enter  loop  to  set  the  iultipliers.  Since  LP  processes  only  MAXIMIZE 

29  C  probleas,  MINIMIZE  objectives  aust  be  converted  by  aul tipiying  the* 

30  C  by  -1.  MAXIMIZE  objectives  are  OK  as  is  and  thus  are  aultiplied 

31  C  1. 

32  C 

33  DO  100  1=1,  NOBJ 

34  1MULTU1  =  1 

35  IF  (  OTYPE (I)  ,E8.  2  )  IHULT(I)  =  -1 

36  100  CONTINUE 

37  C 

38  C  Enter  loop  to  calculate  the  weighted  objective  coefficients  and  store 

39  C  the*  in  P  for  processino  by  LP. 

40  C 

41  DO  200  1  =  1,  NVAR 

42  P(I)  =  0.0 

43  DO  150  J  =  1.  NOBJ 

44  P ( I )  =  P(I)  *  W ( J )  *  OBJ (J, I)  *  IMULT(J) 

45  150  CONTINUE 

46  200  CONTINUE 

47  C 

48  C  set  the  pointer  to  the  SOLN  constraint  array  to  its  initial  condition 


51  C 


52 

C 

call  CONHVE  to  sove  ‘areater  than  or  equal3  constraints  fro#  CON 

53 

C 

(  in  PROS  )  to  d  (  in  SOLN  >. 

54 

C 

55 

CALL  CONHVE  (  3.  IA,  II  ) 

56 

C 

57 

C 

call  CONHVE  to  sove  ‘equal"  constraints  fro#  CON  t  in  PROB  )  to  D 

53 

C 

(  in  SOLN  ). 

59 

C 

60 

CALL  CONHVE  (  2.  NEB,  II  ) 

61 

C 

62 

C 

call  CONHVE  to  sove  ‘less  than  or  equal*  constraints  fro#  CON 

63 

c 

(  in  PROB  >  to  D  (  in  SOLN  ). 

64 

c 

65 

CALL  CONHVE  (  1,  IX,  II  ) 

66 

c 

67 

c 

set  the  nuaber  of  constraints 

68 

c 

69 

IW  =  NCON 

70 

c 

71 

c 

set  the  nuaber  of  variables  (  plus  one  ) 

72 

c 

73 

IY  =  NVAR  +  1 

74 

c 

75 

c 

set  the  nuaber  of  satrix  coluans  (  including  one  for  the  right  hand 

76 

c 

side. 

77 

c 

78 

12  =  IY  +  NE9  +  IX  +  4  2  *  IA  > 

79 

c 

BO 

c 

call  LP  to  get  the  solution. 

81 

c 

82 

CALL  LP  (  114.  IZ,  IY,  IA.  NEB  ) 

83 

CALL  PROANS  (  IZ,  IN  ) 

84 

RETURN 

85 

END 

Prograa  Unit  Length=01 74  (372)  Bytes 
Data  Area  Length=002A  (42)  Bytes 

Subroutines  Referenced: 

til  $T1  m 

$HB  $AB  CONMVE 

LP  PROANS 


Variables: 


14 

/SQLN/+0000 

UB 

/SGLN/+0010 

LB 

/SOLN/ +0020 

DEL 

/SOLN/ +0030 

CON 

/PR06/+0000 

OBJ 

/PR0B/+0212 

RHS 

/PRDB/+01EA 

SQLI4HT 

/S0LN/+05A6 

UBNHT 

/SQLN/+0F5F 

p 

/SQLN/+Q042 

0 

/SOLN/+OOBA 

ZF 

/SQLN/+0F42 

BBJVAL 

/S0LH/+0D62 

VARVAL 

/S0LN/+08B2 

I  MULT 

0001* 

iev 

/SOLN/ ■‘■0592 

CNAME 

/PROB/+0190 

ONAME 

/PRQB/+0282 

FMAME 

/PR0B/+0209 

SPCFLS 

/S0LN/+0F5E 

VARNUil 

/SGLN/+0736 

CNXREF 

/S0LN/+0F54 

CTYPE 

/PROB/+01E0 

OTYPE 

/PR0B/+02D2 

NEON 

/PR0B/+02D6 

NCSJ 

/FR0B/+02D7 

NVAR 

/PR0B/+02D8 

1STRT 

/SOLN/ +0040 

NNDS 

/SOLN/+OF52 

ICAP 

/SOLN/+OF6F 

I 

0009“ 

T; 000000 

0008“ 

T:  000002  000! 

J 

000E“ 

t: oioooo 

0010' 

T: 020000  ooi : 

T : 030000  0014* 

ii 

0016' 

IA 

0018” 

NEQ 

001A* 

IX 

001C“ 

IN 

001 E" 

IY 

0020“ 

12 

0022“ 

COMMON 

Length 

/PR0B/02E1  (737) 

/30LN/0F71  (3953) 

VI  Menu/Hel p  File  Data 


The  following  pages  contain  a  listing  of  the  actual 
menu  and  help  data  as  stored  in  the  menu/help  file.  The 
structure  of  the  menu/help  file  is  described  in  Chapter  II. 

Menus  are  referenced  by  the  various  PCADA  software 
modules  using  the  menu’s  starting  record  number.  In  gener¬ 
al,  all  modules  that  need  to  ask  the  user  a  question  will 
call  one  of  the  input  processors  (GETFLT,  GETINT,  or  6ETTXT) 
with  the  desired  menu’s  starting  record  number  in  the  sub¬ 
routine  calling  sequence. 

Some  subroutines  display  information  or  messages  to  the 
user  that  are  not  in  the  form  of  a  question  or  menu  that 
requires  a  response  from  the  user.  These  displays  are  also 
contained  in  the  menu/help  file  and  are  distinguished  from 
the  others  with  a  special  HELP  text  that  says:  "HELP  not 
applicable  for  this  display...".  For  an  example  of  this 
type  of  menu/help  file  entry,  refer  to  menu  #1. 

A  few  PCADA  questions  contain  variable  data.  These 
menus  are  generated  by  the  software  in  real  time.  However, 
these  menus  still  utilize  the  menu/help  file  in  order  to 
contain  HELP  data  for  the  question.  For  an  example  of  this 


type  of  menu/help  file  entry,  refer  to  menu  #14. 


MENU  NUMBER  1  STARTING  RECORD  NUMBER 


MENU  TEXT  - 


»  t 

*  PERSONAL  COMPUTER  AIDED  DECISION  ANALYSIS  » 

*  t 

*  (PCADA!  * 

*  * 


This  progras  is  designed  to  sieplify  the  decision  salting  process.  It  does  so 
by  providing  an  easy  to  use  tool  tor  solving  aultiole  objective  probless. 

-  HELP  TEXT  - 

HELP  not  applicable  for  this  display... 


MENU  NUMBER  2  STARTING  RECORD  NUMBER  9 
-  MENU  TEXT  - 


— -  GENERAL  INSTRUCTIONS 

Although  aost  prograa  proaots  are  self -explanatory,  you  say  receive  clarifying 
mforaaticn  to  any  question  by  responding  to  it  with  ‘HELP"  or  *?*.  Once  you 
have  defined  a  prooiea  or  loaded  one  fro*  disk,  you  say  have  it  displayed  on  the 
screen  (or  at  the  printer)  by  entering  *(!“  (for  printer  enter  “@P")  in  response 
to  any  question  or  aenu.  Before  continuing,  please  insure  that  you  have  an 
initialized  diskette  for  problea  files  installed  in  disk  drive  2. 

.  HELP  TEXT  - 

HELP  not  applicable  for  this  display... 


MENU  NUMBER  3  STARTING  RECORD  NUMBER  15 
.  MENU  TEXT  - 

WHEN  READY  TO  BEGIN,  PRESS  THE  CARRIAGE  RETURN  BUTTON  <CR> 

.  HELP  TEXT  - 

To  begin  PCADA  processing  you  should  non  press  the  carriage  return  button. 
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MENU  NUMBER  4  STARTING  RECORD  NUMBER  18 


-  MENU  TEXT  - 

PERSONAL  COMPUTER  AIDED  DECISION  ANALYSIS 
(PCADA) 

Probleas  that  you  defined  this  session  have  been  saved  to  disk.  Your  problea 
files  can  be  identified  on  the  problei  diskette  as  those  of  type  *PRB“.  You 
should  take  care  to  sanage  these  files  bv  deleting  or  re-defining  those  that  are 
obsolete.  Also,  please  sake  note  of  your  problea  file  naaes  for  future  use. 


-  END  PROGRAM  - 


-  HELP  TEXT  - 

HELP  not  applicable  for  this  display  .... 


MENU  NUMBER  5  START!. .6  RECORD  NUMBER  24 
-  MENU  TEXT  - 

Before  you  can  solve  a  problea  you  aust  define  a  new  one  or  retrieve  a  previous¬ 
ly  defined  one  froa  disk.  Please  indicate  the  aeans  you  wish  to  use  to  obtain 
an  active  problea  definition'.  (HOTE‘.  To  exit  the  prograa  now,  enter  *0“) 

1.  Load  a  previously  defined  problea  froa  disk 

2.  Define  a  new  problea 

-  HELP  TEXT  - 

Before  actual  problea  solving  can  be  attempted,  you  aust  identify  a  problea  to 
be  solved  together  with  its  paraaeters.  Currently,  no  problea  has  been  defined 
or  activated  froa  disk.  To  exit  the  prograa  now,  enter  *0". 


MENU  NUMBER  6  STARTING  RECORD  NUMBER  30 
-  MENU  TEXT  - 

Please  select  your  next  operation  froa  the  following  aenu: 
(NOTE:  To  exit  the  prograa  now,  enter  "O’) 

1.  Retrieve  a  different  problea  froa  disk 

2.  Define  a  new  problea 

3.  Edit  the  currently  active  problea 

4.  Solve  the  currently  active  problea 


HELP  TEXT 


To  solve  the  probles  currently  in  aeaory,  select  option  4. 
rently  active  probles,  select  option  1,  2,  or  3  as  needed, 
no#,  enter  ’0”. 


MENU  NUMBER  7  STARTING  RECORD  NUMBER  Zb 


To  change  the  cur- 
To  exit  the  prograa 


MENU  TEXT 


Please  enter  the  nase  of  the  proble*  that  you  no#  #ant  to  load  froa  disk: 


HELP  TEXT 


In  order  to  retrieve  a  problea  froa  disk,  you  sust  identify  it  with  the  naae 
that  was  assigned  to  it  when  it  was  originally  defined.  Proble#  file  naaes  are 
froa  2  to  3  characters  in  length  and  aay  contain  no  special  characters  or  lower 
case  letters.  If  you  have  forgotten  your  proble#  file  naae,  you  can  obtain  a 
list  of  all  probleas  by  leaving  this  prograa  and  typing  'DIR  B:\  All  problea 
file  naaes  will  be  of  the  fora  xxxxxxxx.PRB. 


MENU  NUMBER  9  STARTING  RECORD  NUMBER  43 


MENU  TEXT 


DEFINE  NEK  MULTIOBJECTIVE  PROBLEM 


In  this  aodule,  you  Mill  be  defining  a  new  aultioojective  problea  to  be  solved. 
You  should  now  be  prepared  to  enter  the  objective  functions  (up  to  four),  and 
the  constraints  (up  to  ten).  NOTE:  If  you  sake  a  si  stake  on  soae  entry,  you 
can  easily  correct  and/or  sodify  your  problea  later  using  the  EDIT  sodule. 

Also,  your  problea  will  autoaatically  be  saved  to  disk  for  later  use. 

-  HELP  TEXT  - 

HELP  not  applicable  for  this  display... 


MENU  NUMBER  10  STARTIN6  RECORD  NUMBER  54 
-  MENU  TEXT  - 

Please  enter  the  naae  you  wish  to  use  for  referring  to  this  problea: 

(NOTE:  If  you  wish  to  stop  now,  enter  'STOP') 

.  HELP  TEXT  - 

The  naae  you  enter  now  will  he  used  as  a  disk  filenase  for  saving  your  problea 
for  later  use.  Filenaaes  can  be  froa  two  to  eight  upper-case  characters,  say 
contain  no  special  characters,  and  sust  begin  with  a  letter. 


MENU  NUMBER  11  STARTIN6  RECORD  NUMBER  53 
-  MENU  TEXT  - 

The  naae  you  selected  is  already  is  use  as  a  problea  file  naae.  Do  you  wish  to 
redefine  that  problea  now? 

1.  yes 

2.  no 


-  HELP  TEXT  - 

If  you  enter  1,  the  existing  file  will  be  lost  and  you  can  proceed  with  your 
problea  definition.  If  you  enter  2,  the  existing  file  will  be  left  unchanged, 
ana  you  will  be  asked  for  a  different  file  naae. 


MENU  NUMBER  12  STARTING  RECORD  NUMBER  S3 


.  MENU  TEXT  - 

How  sany  variables  does  your  problem  contain? 

-  HELP  TEXT  - 

Prabless  lay  contain  up  to  ten  variables.  These  variables  are  the  unknown 
quantities  that  are  being  solved  Tor  so  as  to  optimize  the  objective 
function ( s) .  It  you  sake  a  si  stake,  you  can  add  or  delete  variables  later 
using  the  EDIT  sodule. 


MENU  NUMBER  14  STARTING  RECORD  NUMBER  71 
-  MENU  TEXT  - 

Please  speciTy  the  objective  function  type: 


1.  Naxiaiaize 

2.  Minisize 

-  HELP  TEXT  - 

The  purpose  of  the  progras  is  to  optimize  some  objective  subject  to  soste  con¬ 
straints.  ton  should  now  specify  whether  the  the  optisal  condition  for  the  current 
objective  is  a  max  or  sin. 


MENU  NUMBER  14  STARTING  RECORD  NUMBER  71 
-  MENU  TEXT  . 

The  senu  contains  variable  data  and  is  generated  prograaaaticaliy... 

-  HELP  TEXT  - 

Enter  the  value  for  the  objective  coefficient  for  the  specified  variable.  If 
the  value  is  zero  just  hit  the  carriage  return. 


MENU  NUMBER  15  STARTING  RECORD  NUMBER  74 
-  MENU  TEXT  - 

Please  enter  the  naae  or  target  quantitv  that  this  objective  represents.  If 
there  are  no  nore  objectives  for  this  problea,  enter  7". 
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HELP  TEXT 


You  aay  now  enter  a  naae  to  associate  with  this  oDjective  function.  This  nase 
is  optional  and  can  be  skipped  by  just  hitting  the  carriage  return. 


MENU  NUMBER  16  STARTING  RECORD  NUMBER  7? 

-  MENU  TEXT  - 

Please  enter  the  nase  of  the  resource  that  this  constraint  represents.  If 
there  are  no  sore  constraints  for  the  probles,  enter  ■/". 

-  HELP  TEXT  - 

You  aay  now  enter  a  nase  to  associate  with  the  constraint.  The  nase  is 
optional  and  aay  be  avoided  by  hitting  the  carriage  return  with  no  input. 


MENU  NUMBER  17  STARTING  RECORD  NUMBER  84 
-  MENU  TEXT  - 

The  eenu  contains  variable  data  and  is  generated  prograasatically... 

-  HELP  TEXT  - 

Enter  the  value  for  the  constraint  coefficient  for  the  specified  variable.  If 
the  value  is  zero,  just  hit  the  return  button. 


MENU  NUMBER  18  STARTING  RECORD  NUMBER  87 
-  MENU  TEXT  - 

Please  specify  the  type  of  relation  applicable  to  this  constraint: 

1.  less  than  or  equal 

2.  equal 

3.  greater  than  or  equal 

-  HELP  TEXT  - 

Constraints  specify  a  lisitina  quantity  that  applies  to  the  allocation  of 
the  scarce  resources.  Please  identify  the  type  of  relation  that  applies  to 
the  constraint. 
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MENU  NUMBER  19  STARTING  RECORD  NUMBER  92 
-  MENU  TEXT  - 

Please  specify  the  right  hand  side  value  for  this  constraint: 

-  HELP  TEXT  - 

You  should  no*  enter  the  liait  applicable  to  the  present  constraint.  If  the 
value  is  zero,  just  hit  the  carriage  return. 


MENU  NUMBER  20  STARTING  RECORD  NUM8ER  95 
-  MENU  TEXT  - 


EDIT  PROBLEM 


This  function  allows  you  to  EDIT  the  probles  that  is  currently  loaded  into 
prograa  aeaory.  Whenever  an  objective,  constraint,  or  variable  is  to  be  ref¬ 
erenced  by  nuaber,  the  nuabers  are  as  they  appear  on  the  problea  printout  that 
can  be  obtained  by  entering  ’8P“  (or  *8“  for  screen)  in  response  to  any  aenu. 

Please  select  froa  the  following  EDIT  functions: 

(NOTE:  Enter  *0"  to  exit  the  EDIT  function) 

-  HELP  TEXT  - 

HELP  not  applicable  for  this  display.... 


MENU  NUMBER  21  STARTING  RECORD  NUMBER  101 
-  MENU  TEXT  - 

1.  Add  objective  function 

2.  Delete  objective  function 

3.  Add  constraint 

4.  Delete  constraint 

5.  Add  variable 

-  HELP  TEXT  - 

Select  the  EDIT  function  as  needed.  For  soae  operations,  you  Bay  have  to  de¬ 
lete  a  constraint  or  objective  and  the  re-add  it  later.  For  exanple,  to  change 
a  MAX  objective  to  a  MIN  or  to  change  an  '='  constraint  to  a  ■<=*  constraint. 


6.  Delete  variable 

7.  EDIT  objective  coefficients 

8.  EDIT  constraint  coefficients 

9.  EDIT  constraint  right  hand  side 
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HENU  NUMBER  22  STARTINS  RECORD  NUMBER  107 


-  MENU  TEXT  - 

Please  specify  which  of  the  above  objectives  you  now  wish  to  delete: 

(NOTE:  Enter  ‘0’  if  you  have  changed  your  sind) 

-  HELP  TEXT  - 

You  have  indicated  that  you  want  to  delete  one  or  sore  objective  functions.  You 
should  now  specify  which  one  by  entering  its  nusber.  Reseaber,  you  aay  obtain  a 
printout  of  your  proble*  at  any  tiae  by  entering  'gP1,  this  printout  lists  the 
objective  functions  and  their  corresponding  nuabers. 


I 

MENU  NUMBER  23  STARTINS  RECORD  NUMBER  112 

- MENU  TEXT -  ■ 

I 

Please  specify  which  of  the  above  constraints  you  now  wish  to  delete: 

(NOTE:  Enter  "0*  if  you  have  changed  your  eind)  * 

- HELP  TEXT -  '' 

You  have  indicated  that  you  want  to  delete  one  or  sore  of  the  constraints  fros 
your  currently  active  probles.  You  should  now  specify  which  one  to  delete  by 

entering  its  nuaber.  Reaesber,  you  say  obtain  a  printout  of  your  probles  at  ! 

any  tiae  by  entering  '§P\  This  printout  lists  all  of  the  constraints  and  their 

nuibers.  j 


HENU  NUMBER  24  STARTINS  RECORD  NUMBER  117 
-  HENU  TEXT  - 

A  variable  has  been  added  to  your  probles.  The  coefficient  values  for  this 
variable  for  all  objectives  and  constraints  has  been  initialized  to  a  value  of 
0.0.  If  you  need  to  alter  these  values,  you  say  do  so  using  the  EDIT  functions 
to  EDIT  objectives  and  constraints  accordingly. 

-  HELP  TEXT  - 

HELP  not  applicable  for  this  display... 


PRESS  THE  RETURN  KEY  WHEN  READY  TO  CONTINUE... 


-  HELP  TEXT  - 

To  resu*e  PCADA  processing  press  the  return  key  no*. 


MENU  NUMBER  26  STARTING  RECORD  NUMBER  125 
-  MENU  TEXT  - 

Please  input  the  nuaber  of  the  variable  you  wish  to  delete'. 

(NOTE:  Enter  ’0“  if  you  have  changed  your  Bind) 

-  HELP  TEXT  - 

You  have  indicated  that  you  want  to  delete  a  variable  trot  your  problet. 

Please  indicate  no*  which  variable  you  want  to  delete  by  entering  its  nutber. 
For  exasple,  to  delete  variable  x3,  enter  3.  NOTE:  The  variables  reaaining  in 
your  problet  will  be  uppacked.  That  is,  if  you  delete  x3,  x4  Mill  becone  x3 
and  x5  will  becote  x 4 ,  etc. 


MENU  NUMBER  27  STARTING  RECORD  NUMBER  130 
-  MENU  TEXT  - 

Please  specify  the  nuaber  of  the  objective  function  whose  coefficients  you 
wGuld  like  to  EDIT:  (NOTE:  Enter  "O'  if  you  are  done  editing) 

-  HELP  TEXT  - 

You  have  indicated  that  you  would  like  to  EDIT  the  coefficients  of  one  or  sore 
of  your  objective  functions.  You  should  no*  specify  which  objective  you  want  to 
EDIT.  Reaesber,  you  can  enter  '8P‘  for  a  printout  at  any  tiae. 


MENU  NUMBER  28  STARTING  RECORD  NUMBER  135 
-  MENU  TEXT  - 

Please  specify  the  nuaber  of  the  coefficient  that  you  would  like  to  change: 
(NOTE:  When  done  editing,  enter  “O') 

-  HELP  TEXT  - 
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You  are  in  the  process  of  editing  constraint  or  objective  coefficients.  You 
should  noM  indicate  which  coefficient  you  want  to  change.  For  a  review  of 
your  problea,  enter  "8P‘  to  recieve  a  proble*  printout.  To  stop  editing  this 
objective  (constraint)  enter  “O'. 


MENU  NUMBER  29  STARTING  RECORD  NUMBER  140 

-  MENU  TEXT  - 

Please  specify  the  new  coefficient  value: 

-  HELP  TEXT  - 

You  are  in  the  process  of  editing  a  constraint  or  objective.  You  should  now 
enter  the  new  value  for  the  specified  coefficient. 


MENU  NUMBER  30  STARTING  RECORD  NUMBER  143 
-  MENU  TEXT  - 

Please  specify  the  nuaber  of  the  constraint  whose  coefficients  you  would  like  to 
EDIT:  (NOTE:  If  you  are  done  editing  coefficients,  enter  '0*) 

-  HELP  TEXT  - 

You  are  in  the  process  of  editing  constraint  coefficients.  You  should  now 
indicate  which  constraint  you  wish  to  EDIT  by  entering  its  nuaber.  To  refresh 
your  aeaory  about  constraint  nuabers,  you  can  now  request  a  printout  of  your 
problea  by  entering  'sP". 


MENU  NUMBER  31  STARTING  RECORD  NUMBER  148 
-  MENU  TEXT  - 

Please  specify  the  nuaber  of  the  constraint  whose  right  hand  side  you  would 
like  to  EDIT:  (NOTE:  If  you  are  done  editing  right  hand  sides,  enter  ‘0") 

-  HELP  TEXT  - 

You  have  indicated  that  you  want  to  alter  one  or  acre  constraint  right  hand 
side  values.  You  should  now  identify  which  constraint  you  want  to  EDIT  by 
entering  its  nuaber.  Recall,  that  you  can  obtain  a  printout  of  your  proble* 
showing  constraints  and  their  nuabers  by  entering  ’GP", 


MENU  NUMBER  32  STARTIN6  RECORD  NUMBER  154 


-  MENU  TEXT  - 

Please  enter  the  new  right  hand  side  value: 

-  HELP  TEXT  - 

You  have  indicated  that  you  want  to  change  constraint  right  hand  sides  and 
should  now  enter  the  new  right  hand  side  value  for  the  constraint  you  have 
indicated.  NOTE:  Right  hand  side  values  MUST  be  positive.  If  yours  is 
negative,  you  aust  convert  the  constraint  by  aultiplying  it  by  -1.  This 
operation  will  change  a  less  than  relation  to  a  greater  than  relation  as  well 
as  changing  the  sign  on  all  of  the  coefficients. 


MENU  NUMBER  33  STARTING  RECORD  NUMBER  160 
-  MENU  TEXT  - 

Please  specify  the  right  hand  side  value  for  this  constraint: 

-  HELP  TEXT  - 

You  should  now  enter  the  liait  applicable  to  the  present  constraint.  If  the 
value  is  zero,  just  hit  the  return  button.  NOTE:  Negative  right  hand  side 
values  are  not  allowed.  If  your  constraint  has  a  negative  right  hand  side,  you 
■ust  convert  it  by  aultiplying  it  by  -1.  In  addition  to  changing  all  co¬ 
efficients,  this  operation  will  change  the  relation  fro*  less  than  to  greater 
than  and  vice-versa. 


MENU  NUMBER  34  START 1N6  RECORD  NUMBER  166 
-  MENU  TEXT  - 

Please  specify  which  problea  solving  technique  you  now  wish  to  use  to  solve  the 
current  problea  (enter  “O'  to  exit): 

1.  The  weighting  technique 

2.  The  constraint  technique 

-  HELP  TEXT  - 

You  should  specify  which  of  the  two  problea  solving  techniques  you  wish  to  use. 
If  you  are  unsure  which  one  is  appropriate,  refer  to  the  users  aanual  or  to  the 
instructional  aodule  of  this  prograa.  In  short,  the  weighting  technique  is 
faster,  and  the  constraint  technique  requires  soae  advance  knowledge  about  the 
objective  function  ranges. 


MENU  NUMBER  35  STARTING  RECORD  NUMBER  172 


MENU  TEXT 


THE  WEIGHTING  TECHNIQUE 


The  weighting  technique  solves  the  problea  by  assigning  weights  to  each  of  the 
separate  objectives,  foraing  a  new  objective,  and  optiaizing  it.  As  a  result, 
the  prograa  will  generate  a  'set*  of  solutions  with  each  one  corresponding  to  a 
different  weight  coabination.  These  "non-dcainated*  solutions  will  be  output 
and  can  then  be  coapared  to  deteraine  which  one(s)  is  fare)  appropriate. 

-  HELP  TEXT  - 

HELP  not  applicable  for  this  display... 


MENU  NUMBER  34  STARTING  RECORD  NUMBER  178 
-  MENU  TEXT  - 

Please  specify  the  weight  increaent  to  be  used  for  this  solution: 
(NOTE:  Enter  "O'  to  exit  the  weighting  technique) 


1. 

1.000 

5. 

0.200 

2. 

0.500 

4. 

0.100 

7 

0.333 

7. 

0.050 

4. 

0.250 

-  HELP  TEXT  - 

The  saaller  the  increaent  you  select,  the  longer  the  prograa  will  run,  and  the 
acre  coaplete  the  solution  set  will  be. 


MENU  NUMBER  37  STARTING  RECORD  NUMBER  183 
-  MENU  TEXT  - 

Please  select  froa  the  following  weighting  technique  solution  options: 
(NOTE:  Enter  *0’  to  exit  the  weighting  technique) 

1.  Solve  with  specific  objective  weights 

2.  Solve  with  a  range  of  weights  on  all  objective  functions 

-  HELP  TEXT  - 
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Option  1  Mill  optimize  the  coabined  objective  only  for  the  1  set  of  Heights 
that  you  Mill  supply.  Option  2  Mill  iteratively  solve  the  problea  for  a  range 
of  Heights  on  each  objective  function.  Initially,  you  should  use  option  2,  use 
option  1  Mhen  you  nant  to  investigate  soae  particular  Height  coabinationts). 


MENU  NUMBER  33  STARTINS  RECORD  NUMBER  18? 

-  MENU  TEXT  - 

Menu  is  generated  prograaaatically... 

-  HELP  TEXT  - 

You  have  specified  that  you  Nish  to  solve  the  problea  using  soae  particular 
Height  coabination.  You  should  non  specify  the  Heights  you  Nant.  Note:  Heights 
aust  be  froa  0  to  1,  but  they  need  NOT  neccessarily  sua  to  1.0.  If  you  enter 
.5,  .5,  and  .5  for  each  of  three  objectives,  the  prograa  Hill  accept  it  and 
weight  each  of  the  three  objectives  equally  (but  not  SOX  each). 


MENU  NUMBER  39  STARTING  RECORD  NUMBER  194 
-  MENU  TEXT  - 


THE  CONSTRAINT  TECHNI8UE 


The  constraint  technique  solves  aulti objective  probleas  by  aafcing  all  but  one  of 
the  objectives  into  equality  constraints  and  optiaizing  the  one  reaaining  ob¬ 
jective.  The  right  hand  sides  of  the  'neH'  constraints  are  bounded  by  the  user 
as  to  the  acceptable  upper  and  loner  liaits.  These  right  hand  sides  are  then 
varied  betneen  the  liaits  to  obtain  a  set  of  acceptable  solutions. 

-  HELP  TEXT  - 

HELP  not  applicable  for  this  display... 


MENU  NUMBER  40  STARTING  RECORD  NUMBER  200 
-  MENU  TEXT  - 


Please  enter  the  upper  acceptable  liait  for  the  above  objective.’ 


You  should  now  specify  the  highest  value  for  the  specified  objective  that  you 
are  Hilling  to  accept  or  that  you  can  reasonably  expect.  You  should  try  to 
insure  that  the  value  you  input  is  in  range,  otherwise,  computing  tiae  Hill  be 
wasted  and  the  final  solution  will  be  less  coiplete. 


MENU  NUMBER  41  STARTING  RECORD  NUMBER  205 
- MENU  TEH - 

Please  enter  the  lowest  acceptable  liait  for  the  objective  function  specified 
above: 

-  HELP  TEXT  - 

You  should  now  input  the  lowest  value  that  is  acceptable  and/or  attainable  for 
the  specified  objective  function.  You  should  try  hard  to  specify  ‘dose*  values 
otherwise,  cosputing  tiie  will  be  wasted  and  the  final  solution  tay  not  be  as 
complete  as  otherwise  possible. 


MENU  NUMBER  42  STARTING  RECORD  NUMBER  210 
-  MENU  TEXT  - 

Please  specify  the  nuaber  of  steps  for  solving  the  problea  in  going  frca  the 
constraint  lower  liait  to  the  upper  liait: 

-  HELP  TEXT  - 

The  higher  the  nuaber  of  steps,  the  aore  tiae  the  solution  will  require  but  the 
■ore  r.on-doainated  solutions  will  be  found.  A  value  of  10  is  a  good  first  try. 


MENU  NUMBER  43  STARTING  RECORD  NUMBER  214 
-  MENU  TEXT  - 

Please  enter  the  nuaber  of  the  solution  that  you  would  like  to  see: 

-  HELP  TEXT  - 

Solution  nuabers  correspond  to  the  objective  suaaary  display.  The  solution  you 
select  will  be  displayed  in  detail,  either  to  the  display  screen  or  the  printer 
as  you  specify.  Also,  following  the  display,  you  will  still  have  an  opportunity 
to  exaaine  other  solutions.  However,  once  you  exit  the  solution  display  nodule, 
solutions  are  lost. 


MENU  NUMBER  44  STARTING  RECORD  NUMBER  219 


-  MENU  TEXT  - 

- >  Tour  probles  had  no  feasible  solutions  < - 

Check  for  error  in  forsulation  and/or  erroneous  constraints/objective  functions 
WHEN  READY  TO  CONTINUE,  PRESS  THE  RETURN  KEY 
-  HELP  TEXT  - 

Your  probles  solution  is  coaplete  and  no  feasible  (or  unbounded)  solutions  Here 
found.  Check  problei  accuracy  and  try  again  and/or  adjust  eeights/liaits. 


MENU  NUMBER  45  STARTING  RECORD  NUMBER  224 
-  MENU  TEXT  - 

At  least  one  unbounded  solution  was  obtained.  This  suggests  a  potential  probles 
forsulation  error.  Please  check  your  probles  carefully.  The  unbounded  solution 
first  occurred  under  the  following  conditions: 

-  HELP  TEXT  - 

HELP  not  applicable  for  this  display... 


MENU  NUMBER  46  STARTING  RECORD  NUMBER  228 
-  MENU  TEXT  - 

- >  Your  single  objective  probles  is  unbounded.  < - 

Check  for  error  in  forsulation  and/or  erroneous  constraints/objective  functions. 
WHEN  READY  TO  CONTINUE,  PRESS  THE  RETURN  KEY 
-  HELP  TEXT  - 


Your  probles  (which  consists  of  a  single  objective  function)  is  unbounded. 
Since  unbounded  solutions  rarely  occur  in  real  life,  your  probles  is  probably 
incorrectly  foraulated.  Please  check  your  probles  carefully  and  try  again. 


MENU  NUMBER  47  START IN6  RECORD  NUMBER  233 


-  MENU  TEXT  - 

Please  specify  your  choice  for  exaaining  problea  solutions: 

(NOTE:  Enter  "O'  to  exit  the  solution  display  aodule) 

1.  Objective  value  suaaary  —  all  solutions 

2.  Detailed  inforsation  —  one  specific  solution 

3.  Detailed  inforsation  --  all  solutions 

-  HELP  TEXT  - 

Select  which  display  option  you  desire.  You  will  be  given  the  choice  to  route 
answers  to  either  the  printer  or  screen.  If  you  specify  "O',  you  will  have  to 
resolve  the  problea  in  order  to  see  the  solutions  again. 


MENU  NUMBER  48  START I N6  RECORD  NUMBER  23? 

-  MENU  TEXT  - 

Would  you  like  your  solution  outputs  to  include  the  objective  weights  that  were 
used  to  obtain  the  corresponding  solution? 

-  HELP  TEXT  - 

If  you  would  like  to  see  the  objective  weights  that  were  used  to  obtain  the 
various  solutions  selest  option  1.  NOTE:  It  is  probable  that  each  solution  is 
obtainable  by  using  aany  different  weight  coabinations. 


MENU  NUMBER  49  STARTINS  RECORD  NUMBER  244 
-  MENU  TEXT  - 

Please  indicate  the  desired  output  device  for  the  solutions: 

1.  Display  screen 

2.  Printer 

-  HELP  TEXT  - 

Solutions  can  be  presented  either  for  quick  reference  on  the  display  screen,  or 
for  peraanent  hardcopy  on  the  printer.  If  you  are  unsure,  select  1  now  to  re¬ 
view  the  answers  and  then  if  desired  select  2  later. 
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